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Abstract 


Two  of  the  main  functions  in  an  office  are  the  communication  and  manage¬ 
ment  of  information.  These  functions  are  currently  handled  by  different  tech¬ 
nologies.  kmessage  management  system  is  an  integration  of  the  capabilities  of 
a  data  base  management  system  and  a  computer-based  message  system. 

We  investigate  the  characteristics  of,  and  present  a  model  for,  message 
management  systems.  This  model  captures  both  the  underlying  data  structures 
and  the  underlying  communication  structures  of  these  systems.  The  work  in 
this  thesis  concentrates  on  the  communication  aspects.  The  model  presented  is 
a  first  attempt  to  apply  data  modelling  techniques  to  the  representation  of 
communication  through  computer-based  message  systems.  The  semantics  of 
communication  in  the  model  are  formalized  using  axioms  in  first-order  predi¬ 
cate  calculus, 

A  subset  of  the  message  management  model,  called  the  addressing  scheme, 
is  used  as  a  framework  for  the  investigation  of  properties  of  message  routing 
within  a  system.  Results  concerning  the  properties  of  completeness,  serializa- 
bility  and  time-independence  are  presented. 

The  applicability  of  the  model  is  demonstrated  through  examples.  One 
example  concerns  the  representation  of  an  existing  mail  system  -  the  Network 
News  bulletin  board  system. 

We  also  discuss  how  our  model  relates  to  the  ISO  Reference  Model  for  Open 
System  Architecture  and  examine  the  characteristics  of  an  architecture  to  sup¬ 
port  message  management  systems, 
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Chapter  1 


Introduction 


There  is  much  emphasis  in  Office  Information  Systems  on  integration  of 
interfaces,  facilities  and  technologies.  Two  important  functions  in  an  office 
which  need  to  be  integrated  are  the  communication  and  management  of  infor¬ 
mation.  At  present  there  are  separate  technologies  to  perform  these  functions  - 
electronic  mail  for  the  communication  and  electronic  filing  for  the  manage¬ 
ment  of  information.  Electronic  mail  is  provided  by  Computer-Based  Message 
Systems  and  electronic  filing  is  closely  related  to  data  base  management.  It  is 
worthwhile,  therefore,  to  investigate  the  integration  of  these  facilities. 

We  define  a  Message  Management  System  (MMS)  to  be  a  system  with  the 
capabilities  of  both  a  Computer-Based  Message  System  (CBMS)  and  a  Data  Base 
Management  System  (DBMS).  Users  of  a  MMS  can  send  and  receive  messages, 
query  the  system  to  find  messages,  accumulate  data  from  the  messages  and 
specify  automatic  processing  and  routing  for  the  messages. 

We  propose  that  a  new  model  is  needed  to  represent  these  MMS’s.  A  model 
that  represents  both  the  underlying  data  structures  and  the  underlying  com¬ 
munication  structure,  and  the  operations  on  these  structures.  The  model  would 
provide  the  MMS  designer  with  a  language  for  describing  the  organization  and 
the  communication  of  information  within  the  MMS.  and  the  MMS  user  with  a 
language  for  manipulating  the  contents  of  the  MMS. 


We  identify  three  main  tasks  in  the  development  of  an  MMS  model: 
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( 1)  the  devclo^  rr-enl.  of  an  ofTiee  data  model  to  represent  the  information; 

(2)  the  develo  rrent  of  a  model  of  communication; 

(3)  the  develo  iient  of  an  interface. 

Work  on  the  de  ./.cpment  of  an  office  data  model  is  described  by  Gibbs  [Gibb83], 
TTie  work  des'.v  .  jd  in  this  thesis  is  concerned  with  the  properties  and  descrip¬ 
tion  of  a  gencr  MVIS  model  (encompassing  both  management  and  communica¬ 
tion  aspects}  V  d  concentrates  on  the  development  of  a  model  of  communica¬ 
tion.  We  feel  Ih  ■■  is  the  main  difference  between  a  MMS  and  a  DBMS.  In  a  DBMS, 
the  users  thr.l  ..'ve  access  to  any  piece  of  information  are  statically  defined  in 
the  schema.  In  j  A'MS,  on  the  other  hand,  there  is  a  dynamic  evaluation  of  the 
set  of  users  "n  '  have  access  to  a  piece  of  information,  that  is,  the  users  that 
receive  the  ini  'tmation  in  the  form  of  a  message.  This  set  of  users  can  also 
change  as  a  r  it  -:age  is  forwarded  around  the  system. 

This  the.sit  describes  a  model  for  message  management  systems  and  inves¬ 
tigates  the  (  oi  aiunication  properties  of  computer-based  message  systems  in 
general.  The  s  coud  chapter  presents  the  background  and  motivation  for  our 
work.  It  firs;,  ’.  oks  at  computer-based  message  systems.  The  next  section 
describes  th^i  \  'rk  that  has  led  up  to  the  introduction  of  the  concept  of  mes¬ 
sage  manage  m  xit  systems.  The  third  section  describes  how  some  office  infor¬ 
mation  systt  m  '  h.andle  communication.  The  fourth  section  examines  object- 
oriented  lang  ur  ‘les  and  Chapter  two  concludes  with  a  discussion  of  the  motiva¬ 
tion  for  our  tne  us. 

The  third  'hapter  describes  our  message  management  model.  The  basic 
components  of  .'le  model  -  messages,  roles,  addresses,  routing  procedures  and 
triggers  -  are  examined  in  turn  and  the  specification  language  presented 
through  the  u  a  of  examples.  A  specification  of  the  language  syntax  for  the 
model  is  given  in  Appendix  1.  The  chapter  next  deals  with  the  operations  in  the 
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model.  We  divide  the  operations  into  two  groups:  those  to  perform  the  manage¬ 
ment  functions  and  those  to  perform  the  communication  functions.  The  last 
section  of  Chapter  three  is  concerned  with  the  formal  semantics  of  the  MMS 
model.  Axioms  in  the  predicate  calculus  are  used  to  describe  the  constraints  on 
communication  in  the  model.  The  semantics  of  the  operations  are  described  in 
terms  of  preconditions  and  postconditions. 

The  fourth  chapter  presents  an  analysis  of  some  of  the  communication 
properties  of  message  addressing  schemes.  We  use  the  concept  of  an  addressing 
scheme  from  our  model  as  the  basis  for  the  analysis.  The  properties  we  investi¬ 
gate  are  completeness,  serializability  and  time-independence. 

The  fifth  chapter  of  the  thesis  contains  two  extended  examples  of  our 
model.  The  first  example  shows  how  we  can  use  our  model  to  conveniently 
represent  an  existing  message  system.  For  this  purpose  we  have  chosen  the 
USENET  system  which  has  advanced  message  system  features.  The  second 
example  is  an  artificial  one  designed  to  show  the  communication  properties  of 
the  model. 

The  sixth  chapter  is  a  discussion  of  the  properties  required  in  a  physical 
architecture  to  support  a  message  management  system.  The  properties  are 
described  in  terms  of  the  ISO  Reference  Model  for  Open  System  Architecture. 

The  seventh  chapter  presents  the  conclusions  and  summarizes  the  contri¬ 
butions  of  the  thesis.  We  also  suggest  areas  of  further  research. 
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Chapter  2 

Background  and  Motivation 

This  chapter  presents  background  and  motivation  for  our  thesis.  We  first 
examine  computer-based  message  systems  (CBMS’s).  We  give  a  brief  overview  of 
the  kind  of  message  systems  available  and  the  facilities  they  ofier  the  user. 
Then  we  look  at  models  of  CBMS's  and  the  problem  of  naming  and  addressing. 
The  next  section  of  the  chapter  introduces  the  notion  of  a  message  manage¬ 
ment  system  (MM3).  We  compare  CBMS’s  with  data  base  management  systems 
(DBMS’s)  and  conclude  they  are  very  similar  and  can  be  considered  instances  of 
a  more  general  system  type.  The  third  section  discusses  communication  in 
office  information  systems  (OIS’s).  The  fourth  section  examines  object-oriented 
languages,  in  particular  Smalltalk.  The  last  section  is  concerned  with  outlining 
the  motivation  for  our  work. 

2. 1 .  Computer-Based  Message  Systems 

Communication  is  one  of  the  fundamental  human  activities  and  its 
efficient  execution  has  become  vital  to  the  running  of  a  business  or  organiza¬ 
tion.  Computer-based  message  systems  are  a  new  communication  medium  with 
the  potential  to  .significantly  reduce  the  amount  of  resources  now  used  by 
organizations  for  communication  and  to  revolutionize  our  methods  of  interper¬ 
sonal  communication  [Bair78,Pank77,Joha78]. 

We  define  a  message  system  to  be  a  medium  that  allows  two  or  more  people 
to  communicate.  Traditionally,  message  systems  have  been  paper-to-paper 
transactions,  and  operated  m  conjunction  with  telephone,  postal  and  other 
communication  services  [KirsSO].  Computer-based  message  systems  are  com¬ 
munication  media  where  computers  act  as  intermediaries.  The  term  CBMS  can 
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be  used  to  encompass  a  wide  range  of  message  systems  -  telex,  teletex,  fac¬ 
simile,  computer  conferencing,  computer  mail.  We  will  restrict  our  use  of  CBMS 
to  refer  to  computer  mail  systems. 

CBMS’s  have  many  important  applications  in  the  area  of  office  information 
systems  [StMcBl,UhFB79,ElNuBl].  They  can  play  a  role  in  several  of  the  activi¬ 
ties  associated  with  office  work,  namely  communicate,  gather,  retrieve,  organ¬ 
ize,  file  and  generate  information.  The  future  importance  of  OIS’s,  and  CBMS’s 
in  particular,  is  assured  by  recent  trends  in  technological  development 
[UhPB79,TsLoBla].  One  such  trend  is  the  falling  cost  of  computer  power  which 
will  soon  make  the  personal  computer  a  practical  tool  of  the  office  worker. 
Another  trend  is  the  decreasing  cost  of  communications.  Distributed  networks 
of  small  machines  are  becoming  viable  solutions  to  organizations’  data  process¬ 
ing  requirements. 

There  are  other  reasons  besides  economic  feasibility  for  incorporating 
CBMS’s  into  the  office  of  the  future  and  eventually  the  home  of  the  future. 
CBMS’s  provide  a  connectivity  among  individuals  that  is  not  available  by  euiy 
other  means.  People  can  interact  on  important  issues  (too  important  for  con¬ 
ventional  post)  without  having  to  carry  out  that  interaction  in  real  time,  Reci¬ 
pients  can  control  when  they  receive  messages.  Phone  calls  often  come  at  an 
inconvenient  time  when  the  recipient  is  involved  in  something  else  or  not  in 
the  proper  frame  of  mind  to  respond.  CBMS’s  are  also  ideally  suited  for  sending 
multiple  copies  of  a  message.  They  require  no  extra  effort  which  makes  coordi¬ 
nation  of  activities  easier,  even  when  the  people  involved  are  geographically 
separated. 

CBMS’s  are  not  intended  to  be  a  substitute  for  other  forms  of  communica¬ 
tion.  Like  the  telephone,  they  are  very  powerful  tools  that  the  office  worker  can 
use  to  communicate  in  the  most  effective  and  efficient  manner.  But  CBMS’s  are 
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a  new  medium  and  require  their  own  protocols  and  etiquette  [Brot83].  They  are 
quite  different  from  other  communication  media  and  allow  a  user  to  reach  a 
wide  audience  with  little  or  no  extra  effort.  Only  experience  will  teach  us  the 
proper  way  to  use  this  tool.  It  is  very  likely  that  office  communication  will 
require  restructuring  to  take  advantage  of  the  electronic  mail  [HiTuBO], 

Message  systems  have  advanced  in  recent  years  and  become  widely 
accepted.  This  acceptance  has  brought  a  large  variety  of  mail  systems  to  serve 
different  communities  of  users.  Most  computer  systems  provide  a  mail  facility 
for  its  local  users,  for  example  the  Mail  programs  under  UNDC^  [Shoe79].  There 
are  also  commercial  systems  like  MAILBOX  (I.P.  Sharpe)  and  COMET  (Computer 
Corporation  of  America)  for  larger  communities  of  users.  There  are  systems  for 
special  groups,  such  as  CSNET  [DennBB]  or  MSG  [VittBl],  or  for  special  purposes, 
such  as  USENET  [Horton].  Among  the  special  purpose  systems  are  a  number 
designed  for  computer  conferencing,  for  example  EMISARI  and  EIES  [HiTu7B]. 

A  CBMS  provides  three  general  functions;  message  creation,  message 
transfer  and  recipient  processing  [MulvBSj.  To  aid  in  message,  creation  a  sys¬ 
tem  usually  provides  text-editing  facilities  to  review  and  modify  a  message 
before  posting.  “When  a  message  is  ready  to  be  posted  the  originator  passes  the 
message  and  a  list  of  recipients  to  the  message  transfer  part  of  the  system. 
Once  delivered,  a  message  is  stored  until  the  recipient  requests  his/her  mail. 
In  many  CBMB’s  a  recipient  is  notified  of  new  messages  (on  request  or  at  logon) 
and  given  a  summary  of  each  message.  Recipients  are  also  provided  with 
software  to  read,  print,  store  and  retrieve  messages.  Some  other  services  pro¬ 
vided  by  current  CBMS’s  are  message  forwarding,  reply  generation,  logical 
addressing  where  recipients  are  defined  by  a  set  of  attributes,  broadcast 
addressing,  group  addressing,  message  circulation  and  cross-referencing  of 


1.  UNIX  is  a  trademark  of  Bell  Laboratories 
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niessage's, 

A  model  of  a  CBMS  is  shown  m  Figure  2.1.  The  C/ser  Agent  (UA)  is  a  set  of 
processes  vvhich  a  user  can  access  to  create,  present  and  store  messages.  The 
Message  Transfer  System  (MTS)  is  an  entity  that  accepts  a  message  from  an 
originator’s  UA  and  passes  it  to  each  recipient's  UA.  The  MTS  is  dedicated  to  the 
transfer  of  messages  and  the  management  of  auxiliary  information  such  as 
address  directories  and  billing  histories.  The  MTS  is  further  divided  into  func¬ 
tional  cooperating  components  called  Message  Transfer  Agents  (MTA’s)  which 
facilitate  the  delivery.  The  posting  slot  is  the  point  at  which  responsibility  for  a 
message  passes  from  the  originator's  UA  to  the  MTS,  The  delivery  slot  is  the 
point  at  which  the  MTS  passes  responsibility  for  a  message  to  a  recipient’s  UA. 
In  this  model  a  message  is  considered  to  be  composed  of  two  parts:  the  message 
header  or  envelope  and  the  message  contents.  The  contents  contain  the  infor¬ 
mation  the  originator  wishes  to  send  and  the  header  is  a  fixed  set  of  fields 
which  specifies  the  information  required  by  the  MTS.  Detailed  discussions  of 
CBMS  models  can  be  found  in  papers  by  Mulvenna  [MulvBS]  and  by  Garcia-Luna 
and  Kuo  [GaKuBS], 

One  of  the  major  problems  that  must  be  considered  in  any  CBMS  is  that  of 
naming,  addressing  and  routing  [SchiBS],  The  addressing  mechanism  used  in 
the  telephone  or  telex  systems,  i.e,  digit  addresses,  is  an  inadequate  form  of 
communication  from  a  human  engineering  point  of  view.  The  technology  avail¬ 
able  makes  it  possible  for  systems  to  be  adapted  to  human  behaviour  patterns 
rather  than  the  reverse  situation.  A  minimum  requirement  is  that  the  address¬ 
ing  facility  should  perform  the  same  functions  as  the  conventional  mail  system, 
1  e.  a  recipient  designated  by  a  postal  address.  We  could  go  even  further  and 
allow  names,  postal  addresses,  membership  in  a  group  or  organization,  or  even 
characteristics,  to  identify  a  recipient.  It  is  up  to  the  CBMS  to  map  this  "logical" 
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Figure  2.1:  Model  of  a  CBMS 
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address  to  the  "physical"  address  it  uses  as  the  location  of  that  recipient. 
Another  aspect  of  the  problem  is  the  flexibility  o'  the  association  of  users  to 
physical  addresses.  Users  may  change  their  location  or  even  leave  the  system 
entirely.  Traditional  solutions  forwarded  messages  from  a  user's  old  address  to 
his  new  one,  or  to  informed  all  users  of  any  address  changes. 

Today's  electronic  mail  systems  are  mostly  text-oriented.  However  work  is 
being  done  to  incorporate  other  kinds  of  information  such  as  images,  voice  and 
structured  fields  [TCEF83].  Another  possible  featur  e  of  advanced  CBMS’s  is  an 
active  message  capability  [VittBlb,  HMGTB3]  which  allows  messages  to  perform 
some  actions  on  their  own.  This  capability  would  allow  the  sender  of  a  message 
to  specify  his/her  intentions  about  what  can  be  done  with  that  message,  and 
how  it  should  look  and  behave  when  a  recipient  asks  to  see  it. 

An  example  of  such  a  system  is  the  intellirvnt  message  system  or  Imail 
[HMGT83].  Messages  have  the  ability  to  accomplish  complicated  tasks  such  as 
collecting  responses  from  recipients  or  routing  themselves  to  recipients 
according  to  predefined  rules.  An  intelligent  message,  or  imessage,  is  a  pro¬ 
gram  that  is  run  by  the  recipient.  Through  this  i>rogram  the  originator  of  the 
imessage  can  incorporate  rules  which  will  govern  the  interaction  of  the  imes¬ 
sage  with  its  recipients  at  run  time. 

A  response  in  a  conventional  CBMS  must  be  created  by  the  recipient  and 
shipped  to  the  originator  as  a  separate  message.  However  an  imessage  can  col¬ 
lect  responses  provided  by  the  recipients,  store  them  and  eventually  make 
them  available  to  its  originator. 

Conventional  mail  systems  require  the  sender  to  specify  all  of  the  reci¬ 
pients  at  message  sending  time  This  kind  of  rouli.ig  is  static  in  the  sense  that 
the  message  will  only  visit  these  prespecified  recipients.  An  imessage  can  route 
itself  dynamically  in  response  to  interactions  with  recipients.  Initially  an 
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imessage  must  be  given  at  least  one  recipient.  Future  destinations  may  be 
added  later  as  a  result  of  an  Ima.il.  session.  These  destinations  may  be  "con¬ 
stants"  specified  by  the  originator  and  only  used  if  certain  criteria  are  met  dur¬ 
ing  a  session;  they  may  be  given  as  responses  by  a  recipient  and  thus  totally 
unkno-vm  to  the  originator,  or  they  may  be  the  result  of  some  arbitrary  func¬ 
tion,  such  as  a  data  base  access. 

2.2.  Message  Management  ^sterns 

We  now  outline  the  work  done  by  Tsichritzis  [TsicBl]  that  was  the  initial 
impetus  for  our  investigation.  The  concept  of  a  message  management  system 
came  about  because  of  the  perceived  need  to  integrate  the  exchange  and 
storage  of  messages  in  an  office.  In  an  attempt  to  view  ideas  on  message  sys¬ 
tems  and  data  base  meinagement  systems  within  a  common  framework,  Tsi¬ 
chritzis  examines  the  similarities  and  the  differences  between  the  concepts  and 
the  techniques  used  in  the  two  system  types.  He  concludes  that  the  differences 
are  not  nearly  as  great  as  we  would  expect  and  that  the  integration  of  the  two 
system  functions  within  a  common  framework  is  possible. 

CBMS’s  and  DBMS's  exist  to  provide  different  functions.  DBMS’s  record  and 
interpret  information;  CBMS’s  communicate  information.  But  communication  is 
implicit  in  the  operation  of  recording  information.  By  recording  some  data  we 
communicate  the  information  they  represent  to  anybody  else  having  access  to 
the  data.  Even  in  the  case  of  a  personal  data  base,  the  data  base  communicates 
information  in  the  future.  That  is,  the  same  user  who  recorded  the  information 
can  inspect  it  at  a  later  time. 

The  first  difference  between  CBMS’s  and  DBMS's  is  the  target  of  communi¬ 
cation,  i.e.  those  users  potentially  affected  by  the  information  in  a  message  or 
record.  In  a  message  system,  the  target  of  a  message  is  well-defined.  The 
default  is  usually  an  individual.  In  the  data  base  case,  the  effect  of  a  transaction 


- 11  - 


(implicit  commuriicatir>r)}  is  supposed  to  be  felt  by  everyone  who  has  access  to 
the  data  changed  by  the  transaction.  The  default  is  a  broadcast  operation.  So  at 
least  in  the  default  cases,  there  is  a  difference  in  the  targets.  But  this  situation 
is  changing.  Broadcast  and  group  targets  are  possible  in  message  systems, 
while  on  the  other  hand,  data  base  views  make  individual  targetting  of  transac¬ 
tions  plausible. 

A  second  difference  is  with  respect  to  notification.  A  message  is  supposed 
to  be  delivered  Lo  a  recipient.  That  is,  the  recipient  is  alerted  to  the  presence  of 
the  message.  In  a  data  base,  the  effect  of  a  transaction  is  simply  posted  without 
any  notification.  A  user  has  to  issue  a  separate  operation  to  retrieve  the  data 
and  receive  the  information  This  difference  is  related  to  targetting.  In  message 
systems,  the  target  is  well-defined  so  we  know  whom  to  notify.  In  data  base  sys¬ 
tems,  the  effect  of  a  transaction  is  global.  This  difference  of  notification  is 
disappearing.  In  many  message  systems  users  can  set  up  mailboxes  to  receive 
their  mail.  The  users  pick  the  messages  they  want  at  their  own  initiative.  In 
data  base  systems,  we  could  produce  side  effects  to  transactions  which  provide 
alerts  to  interested  parlies. 

A  third  difference  is  the  imposition  of  structure  on  data.  Messages  have 
evolved  free-format.  Tliey  are  usually  defined  as  a  header  and  a  body  with  no 
restrictions  on  the  format  of  the  contents.  The  absence  of  formatting  require¬ 
ments  make  messages  simpler  to  use  for  informal  communication.  Bata  base 
records,  on  the  other  hand,  have  a  very  strict  format.  This  difference  in  terms 
of  structure  is  diminishing.  Bata  base  research  perceives  the  need  for  handling 
text,  voice  and  pictures.  Some  message  systems  recognize  the  need  to  exploit 
the  structure  present  in  the  contents  of  individual  messages.  Examples  are  the 
forms  systems  where  the  structured  office  form  is  the  basic  unit  of  communica¬ 


tion. 
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A  fourth  difference  deals  with  the  interpretation  of  messages  and  data  base 
records.  By  interpretation  we  mean  the  general  rules  for  interpreting  the  con¬ 
tents  of  a  message  or  record.  Messages  carry  their  own  interpretation,  i.e.  the 
universal  rules  of  the  natural  language  of  the  contents.  There  is  no  separation 
of  data  and  interpretation.  The  interpretation  for  data  base  records  is 
abstracted  and  forms  a  separate  part  of  the  data  base,  namely  the  schema. 
This  difference  is  also  disappearing.  In  knowledge  based  systems,  meta-data  and 
data  are  mixed  [TsLoSlb]  and  in  forms  systems,  messages  have  a  separate 
interpretation  in  terms  of  their  templates  [Tsic82]. 

A  final  difference  between  messages  and  data  base  records  is  ownership, 
i.e.  whether  a  particular  person,  station  or  process  has  control  over  a  message 
or  record.  In  a  message  system  a  message  is  initially  owned  by  the  sender.  It  is 
transferred  to  the  message  transport  system  and  then  eventually  to  the 
receiver.  A  data  base  record  is  always  owned  by  the  data  base  system  which 
grants  access  to  particular  users.  The  execution  of  a  transaction  does  not  imply 
a  change  of  ownership.  This  difference  is  a  direct  result  of  the  global  versus  per¬ 
sonal  view  of  information.  Messages  are  considered  private  property  while 
records  are  considered  common,  i.e.  kept  by  the  system  for  the  general  public. 
This  is  a  distinction  of  degree  rather  than  substance.  In  message  systems  the 
message  is  owned  by  the  system  while  in  transport.  One  can  claim  that  this 
system-owned  message  is  the  real  message.  The  sender  just  constructs  an 
image  eind  the  receiver  obtains  an  image.  Also,  we  can  consider  a  transaction  to 
go  through  three  stages  of  ownership.  A  user  initiates  a  transaction  which 
implies  that  he /she  temporarily  owns  an  image  of  the  data  base  record.  In  fact, 
locking  ensures  this  temporary  ownership.  When  the  transaction  is  completed 
the  records  are  released  and  ownership  reverts  back  to  the  system.  Finally, 
another  user  obtains  temporary  ownership  of  the  record  in  order  to  observe  the 
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affects  of  the  transaction.  From  this  point  of  view  message  and  data  base  sys¬ 
tems  go  through  similar  stages  of  ownership. 

Based  on  the  above  observations,  Tsichritzis  concludes  that  it  is  possible, 
and  even  desirable,  to  integrate  the  two  system  types  and  provide  a  common 
model.  The  result  of  this  integration  is  what  we  call  a  message  management 
system.  A  MMS  extends  a  CBMS  and  makes  it  more  useful  in  the  office.  The  sys¬ 
tem  can  do  something  "intelligent"  with  messages,  such  as  sorting  messages 
according  to  contents,  t37pe  or  originator,  filtering  incoming  messages, 
automatically  routing  messages  or  querying  the  messages  on  file. 

2.3.  Consminication  in  CHS's 

We  view  CBMS's  or  MMS’s  as  a  part  of  an  integrated  OIS.  It  is  worthwhile  to 
examine  how  communication  is  treated  in  some  of  the  work  done  in  OIS 
research. 

One  of  the  main  features  of  OIS  work  is  the  automatic  processing  of  infor¬ 
mation.  An  aspect  of  this,  with  respect  to  communication,  is  implicit  destina¬ 
tion  specification,  that  is,  the  system  takes  responsibility  for  the  routing  of 
individual  messages.  So  instead  of  providing  a  set  of  destinations  for  every  mes¬ 
sage  a  user  wishes  to  send,  the  user  is  required  to  specify  a  set  of  rulesj  to 
govern  the  routings  of  the  messages.  This  automation  is  possible  because  of  the 
large  amount  of  redundancy  in  office  work.  We  can  identify  "classes"  of  mes¬ 
sages  that  are  all  treated  the  same.  Automatic  routing  should  be  a  feature  of 
any  MMS. 

One  method  of  providing  automatic  routing  is  through  the  use  of  office 
procedures  [TRGNB2,SLTCB2,Zd.sm77].  In  the  prototype  system  of  Tsichritzis  et. 
al.  [TRGNB2],  a  procedure  can  be  specified  in  a  station  which  will  be  automati¬ 
cally  triggered  by  the  presence  of  messages.  Procedures  are  specified  by  com- 
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pleting  sketches  which,  indicate  the  preconditions  and  actions  for  the  pro¬ 
cedure.  Once  the  preconditions  are  met,  the  actions  are  triggered.  Procedures 
can  perform  such  actions  as  copying  messages,  or  forwarding  messages  to 
other  stations,  or  coordinating  a  set  of  messages.  Using  this  automatic  routing 
facility  makes  the  set  of  destinations  for  a  message  very  dynamic.  " 

Another  example  of  an  automatic  routing  facility  is  foimd  in  the  work  of 
Chang  and  Chang  [ChChBS].  Here  the  authors  approach  the  problem  of  office 
activities  management  from  the  data  base  viewpoint.  They  feel  that  an  OIS 
requires  the  support  of  a  DBMS  for  the  storage  and  manipulation  of  information. 
This  DBMS  can  be  made  responsive  to  external  events  through  the  use  of  data 
base  alerters. 

A  data  base  alerter  is  a  Kcondition,  actiort>  pair.  The  condition  specifies  an 
operation  on  a  data  base  object.  The  data  base  is  monitored  and  when  the  condi¬ 
tion  is  met,  the  accompanying  action  is  taken.  The  action  can  involve  the  gen¬ 
eration  of  some  message  and  the  forwarding  of  it  to  another  station.  Special 
types  of  alerters  have  well-defined  durations  or  can  handle  time-related  events. 

Again,  as  in  the  previous  system,  message  routing  is  automatic.  But  mes¬ 
sages  are  secondary  objects  to  the  information  stored  in  the  data  base.  In  the 
first  system  there  was  only  one  class  of  objects;  the  messages  contained  the 
information  and  were  routed  around  the  system. 

The  QBE  system  [ZI008O]  also  employs  triggers  to  provide  an  automatic 
routing  facility.  The  destination  can  be  a  single  recipient  or  a  distribution  list. 
In  the  latter  case  each  recipient  gets  his/her  own  copy  of  the  message. 

The  routing  done  in  the  previous  examples  is  all  "single-hop"  [Maze83], 
that  is,  the  whole  flow  of  the  message  through  its  entire  existence  is  not 
specified,  just  one  step  consisting  of  the  routing  from  one  station  to  one  or 
more  other  stations.  The  work  by  Mazer  [Maze83]  provides  a  routing 
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specification  for  the  whole  tour  of  a  message  and  allows  destinations  to  be 
determined  according  to  the  current  system  state  and  the  contents  of  the  mes¬ 
sage. 

Routing  specifications  can  be  given  for  message  types,  which  mean  they 
apply  for  all  instances  of  the  type,  or  for  individual  messages.  A  routing 
specification  consists  of  the  logical,  paths  to  be  taken  by  a  message  plus  the 
decision  criteria  to  choose  among  those  paths.  The  logical  routing  of  a  message 
is  expressed  in  terms  of  the  recipients  (or  sites)  that  can  see  that  message. 
This  differs  from  the  physical  routing  the  message  takes  over  the  supporting 
computer  networks  to  reach  each  of  the  recipients. 

A  routing  specification  for  the  message  type  "time-card"  is  shown  in  Figure 
2.2.  All  messages  of  the  type  are  routed  in  the  defined  manner.  A  specification 
can  include  one  or  more  user-defined  distribution  lists.  A  distribution  list  "log- 
cash"  is  defined  in  "time-card"  to  be  composed  of  the  sites  "ledger-clerk"  and 
"cashier". 

The  routing  of  "time-card"  messages  occurs  at  the  site  "supervisor"  and  at 
the  group  of  sites  designated  by  the  role  abstraction  "<employee>".  The  inclu¬ 
sion  of  "SOURCE"  for  the  sites  "<employee>"  means  that  the  sites  are  able  to 
originate  messages  of  the  type  "time-card". 

The  routing  is  defined  in  terms  of  cases.  One  level  of  cases  is  the  number  of 
times  a  message  has  visited  a  site.  The  options  are  CREATION  (when  a  message 
first  created),  FIRST  (the  first  visit  by  a  message),  SECOND,  and  so  on.  The 
default  option  is  labelled  OTHER.  Within  this  first  level  other  cases  may  be 
specified  that  depend,  upon  content  values,  the  previous  sites  visited  by  a  mes¬ 
sage,  or  Lime  constraints  on  the  processing  of  the  message  by  the  sites.  For 
example,  the  routing  from  the  site  "supervisor"  depends  upon  the  value  of  the 
field  "approval"  in  the  "time-card"  message. 
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MESSAGE  'VrPF.  time-card 

DEFINE  log-cash  =  ledger-clerk  &  cashier 

SITE  <employee>  SOURCE 
CREATION 
TO  supervisor 
OTHER 

TO  supervisor 
END 

SITE  supervisor 
OTHER 

CASE  ?approval  =  "yes"  TO  log-cash 
CASE  ? approval  =  "no"  TO  ORIGIN 
END 

Figure  2.2:  Example  Roviing  Specification 

The  work  done  by  Mazer  is  similar  to  the  work  presented  in  this  thesis  but 
is  at  a  higher  level.  We  concentrate  on  the  routing  that  must  be  done  within  a 
MMS  to  transfer  a  message  from  one  site  to  another.  We  model  exactly  how  a 
message  is  circulated  within  a  system.  Our  MMS  model  presents  a  more  general 
notion  of  routing. 

2.4.  Object-Oriented  Languages 

The  development  of  ol^ect- oriented  languages  has  been  closely  linked  with 
the  development  of  office  information  systems.  The  concurrency  and  distribu¬ 
tion  allowed  by  the  message-passing  paradigm  are  ideal  for  OIS  software.  A  sys¬ 
tem  is  composed  of  a  set  of  objects  that  interact  by  sending  and  receiving  mes¬ 
sages,  or  requests.  An  object  is  basically  some  data  plus  some  rules  that  define 
the  object’s  interaction  with  other  objects. 

The  best  known  object-oriented  language  is  Smalltalk  [Bjd.e81].  Both  data 
and  its  manipulation  are  represented  by  a  single  entity,  the  object.  Information 
is  manipulated  by  sending  a  request  to  the  object  representing  the  information. 
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The  object  then  determines  how  to  manipulate  itself.  An  object  reacts  to  a 
request  by  performing  a  corresponding  method.  A  method  describes  a  sequence 
of  actions  to  be  taken  which  consist  of  sending  other  requests,  assigning  values 
to  local  variables  and  returning  a  value  to  the  originator  of  the  request. 

Every  object  is  an  instance  of  a  class.  Each  member  of  the  class  has  simi¬ 
lar  properties,  or  instance  variables,  and  responds  to  the  same  requests  with 
the  set  of  methods  provided  by  the  class.  Smalltalk  provides  for  a  default  inher¬ 
itance  between  its  classes,  but  only  in  a  hierarchy.  Subclasses  inherit  every¬ 
thing  from  their  superclasses  (instance  variable  names  and  methods)  unless 
the  features  are  explicitly  overridden. 

Actors  are  another  well-known  object-oriented  formalism  [Grei75,Hewi77j. 
Originally,  actors  were  presented  as  a  new  model  of  computation.  But  the  actor 
formalism  has  the  following  characteristics  which  make  it  ideally  suited  for  the 
development  of  OIS's  [BySJQS]: 

(1)  Instances  of  actor  types  are  the  executing  and  communicating  entities  in 
the  system.  Their  behaviour  is  specified  by  a  "script"  and  they  have 
memory  which  persists  between  invocations. 

(2)  An  actor  communicates  with  other  actors,  known  as  its  "acquaintances", 
via  messages.  It  is  transparent  to  an  actor  sending  or  receiving  the  mes¬ 
sage  whether  the  other  actor  is  at  the  same  node  or  at  a  different  node  in  a 
network  of  computers 

(3)  Actors  execute  asynchronously  upon  the  receipt  of  a  message. 

(4)  Actors  are  highly-modular  with  well-defined  interfaces.  One  cannot  look 
inside  an  actor  One  only  knows  its  behaviour  in  terms  of  the  types  of  mes¬ 
sages  it  accepts  and  the  way  it  responds  to  those  messages. 
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(5)  Every  object  is  an  actor;  in  particular,  the  messages  are  actors. 

Byrd  et,  al.  [BySJBS]  describe  aa  actor-based  programming  system  with  features 
similar  to  Smalltalk. 

The  object-oriented  approach  is  useful  for  emphasizing  the  communication 
in  a  MMS.  The  approach  is  also  suited  for  handling  the  distribution  of  processes 
in  a  MMS.  But  Smalltalk  and  the  actor  approach  are  programming  languages. 
They  are  intended  to  describe  processing,  not  data.  They  lack  the  rich  type 
structuring  mechanisms  of  semantic  data  models  that  are  necessary  to  concep¬ 
tually  represent  a  MMS.  Also  the  single  object  or  actor  as  a  representation  for 
everything  is  too  general  to  be  of  value  in  describing  a  MMS. 

We  feel  that  the  applicability  of  object-oriented  languages  to  MMS’s  is  as  an 
implementation  tool  for  such  systems  An  object-oriented  language  makes  any 
underlying  distribution  transparent.  .Also  the  t3T)e  definitions  of  our  model. 
*^hich  are  presented  in  Chapter  three,  combine  data  and  procedures,  which 
makes  objects  a  suitable  implementation  mechanism. 

2.5.  Motivation 

We  have  seen  the  importance  of  managing  and  communicating  information 
in  the  office  environment.  There  is  a  need  to  integrate  the  facilities  that  pro¬ 
vide  these  operations  if  we  are  to  produce  effective  office  information  systems. 
The  notion  of  a  message  management  system  integrates  the  facilities  of 
computer-based  message  systems  and  data  base  management  systems.  Existing 
CBMS  models  are  not  able  to  represent  MMS’s.  One  of  the  main  reasons  is  the 
inclusion  of  structure  on  the  contents  of  messages  and  the  ability  of  MMS’s  to 
partially  interpret  this  structure.  We  have  to  look  elsewhere  for  this  modelling 
ability  -  semantic  data  models  [HaMcBl,SmSm77,MyBW80]. 

Semantic  data  models  provide  abstraction  mechanisms,  which  allow  us  to 
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hide  unwanted  detail,  and  to  construct  higher-level  structures  from  a  number 
of  lower-level  ones  or  from  structural  primitives.  The  three  abstraction 
mechanisms  commonly  identified  are  classification,  generalization  and  aggre¬ 
gation.  Classification  views  a  set  of  objects  as  one  generic  t3^e.  Generalization 
allows  us  to  combine  one  or  more  types  into  a  single  type.  Aggregation  is  the 
abstraction  by  which  an  object  is  viewed  as  a  collection  of  property  values. 
Another  form  of  aggregation,  knovm  as  cover  aggregation  or  grouping,  is  impor¬ 
tant  to  the  development  of  an  office  data  model  and  is  discussed  by  Gibbs 
[GiTs83], 

Data  models  alone  have  several  shortcomings  and  can  not  adequately 
represent  MMS’s.  First,  data  models  supply  only  a  global  notion  of  data.  MMS’s 
emphasize  local  data  and  the  concept  of  ownership  of  data.  Second,  an 
extremely  important  aspect  of  MMS’s  is  the  routing  of  messages  by  the  system. 
Data  models  do  not  have  facilities  to  capture  this  routing.  Also,  data  models  are 
not  able  to  represent  the  target  of  a  message,  except  perhaps  as  a  property. 
Finally  MMS’s  contain  a  lot  of  activity;  what  the  actions  are  and  where  they  take 
place  are  very  important  properties  that  must  be  modelled.  Data  models 
emphasize  structure  and  relationships,  not  actions.  In  addition,  data  models 
can  not  represent  the  fact  that  some  of  the  relationships  and  actions  in  a  MMS 
are  dependent  upon  the  location  of  the  data. 

The  new  model  we  propose  incorporates  the  abstraction  mechanisms  and 
the  operations  from  semantic  data  models.  We  apply  data  modelling  techniques 
for  the  first  time  to  the  area  of  message  systems.  We  are  also  able  to  give  the 
formal  semantics  of  communication  in  a  message  system  using  these  tech¬ 
niques.  The  previous  wcrk  on  modelling  message  systems  has  not  performed 
this  formalization.  'Phe  formalization  is  based  on  the  notion  of  ownership  as  a 
representation  of  communication.  We  are  able  to  capture  properties  of  both 
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data  base  and  message  systems  -  in  particular  the  targettlng  of  messages  and 
shared  access  by  users  to  a  single  logical  message.  This  latter  property  is  not 
available  in  previous  C.BMS  models. 

Another  limitation  of  current  CBMS's  is  static  logical  rorUrvng.  An  originator 
must  know  in  advance  the  names  of  all  the  recipients  and  perhaps  even  the 
paths  to  these  recipients,  A  user  does  not  always  have  this  information.  A  user 
may  know  only  a  subset  of  all  the  people  that  should  receive  information,  or  a 
user  may  have  only  partial  knowledge  about  the  recipients.  For  example,  a  mes¬ 
sage  must  go  to  the  accounting  department  but  the  user  does  not  know  which 
member  of  the  department  should  process  the  message. 

Our  model  provides  for  dynamic  logical  routing.  The  system  shares  respon¬ 
sibility  with  the  originator  of  a  message  for  determining  and  finding  the 
appropriate  recipients  of  that  message.  The  system  can  decide  based  upon  the 
contents  of  the  message  and  the  current  system  state.  It  is  also  possible  to 
have  this  routing  knowledge  logically  distributed,  i.e.  each  routing  entity  has 
partial  knowledge  and  the  message  routing  is  determined  a  step  at  a  time.  An 
example  of  this  kind  of  distribution  is  the  post  office.  Mail  is  passed  up  and  down 
a  hierarchy  of  mail  terminals  where  each  terminal  only  requires  knowledge  of 
those  terminals  connected  to  it  by  the  hierarchy. 

V*'c  make  the  distinction  between  logical  and  physical  routing.  In  a  logical 
routing,  a  series  of  decisions  are  made  that  eventually  result  in  the 
identification  of  a  set  of  recipients  for  a  message.  The  knowledge  to  make  these 
decisions  ma;/  be  distributed  among  a  network  of  logical  nodes.  The  actual  phy¬ 
sical  distribution  of  the  logical  nodes  is  transparent.  One  step  in  the  logical 
routing  may  involve  several  steps  in  the  physical  routing  -  over  one  or  more 
local  area  nctv/orks  and  a  long-haul  network.  Alternatively,  two  or  more  logical 
nodes  may  be  in  the  same  physical  host. 
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We  present  an  analysis  of  some  properties  of  message  systems.  Working 
from  the  framework  our  model  provides  we  examine  the  properties  of  complete¬ 
ness,  serializability  and  time-independence  as  they  apply  to  message  systems. 
From  this  analysis  we  are  able  to  determine  if  a  particular  message  system  is 
guaranteed  to  deliver  all  its  messages;  if  a  particular  message  system  routes 
messages  in  the  way  we  intended  and  if  the  length  of  time  a  message  spends  in 
a  system  is  guaranteed  not  to  affect  its  final  destinations. 

This  thesis  presents  an  initial  investigation  into  a  new  and  powerful  system 
t>’pe  that  we  feel  will  play  a  major  role  in  OlS's.  The  model  described  will  be  an 
aid  to  the  designers  of  message  management  systems  and  a  descriptive  tool  for 
their  users.  Our  work  on  the  formalization  of  communication  will  hopefully  aug¬ 
ment  our  understanding  of  message  management  systems  in  the  same  way  the 
initial  formal  work  in  data  base  theory  added  to  the  understanding  of  data  base 
systems. 
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Chapter  3 


Message  Memagement  System  Model 


The  main  feature  of  message  management  systems,  and  message  systems 
in  general,  that  we  wish  to  represent  is  communication.  The  main  objects  in  the 
model  are  messages,  addresses  and  roles.  Communication  is  represented  as 
changes  in  the  ownership  of  messages  by  roles  and  addresses.  We  define  our 
^iMS  model  to  consist  of  six  components: 

(  I)  a  communication  space; 

(2)  a  type  definition  language; 

(3)  manipulation  operations; 

('l)  circulation  operations; 

(5)  a  predicate  language; 

(6)  control  structures. 

This  model  structure  is  adapted  from  the  work  on  data  models  by  Smith  and 
Smith  [SmSm79]. 

The  communication  space  contains  a  set  of  individuals  and  the  relation¬ 
ships  between  them.  The  individuals  can  be  primitives  (messages,  roles  and 
addresses)  or  types  (message  types,  role  types  or  address  types).  The  relation¬ 
ships  among  the  individuals  are  required  to  represent  the  semantics  of  com¬ 
munication.  Three  relationships  present  in  semantic  data  models  can  be  used 
in  our  MMS  model  to  give  messages  a  rich  t3q)e  structure: 

(1)  specialization  -  type  is-a  type; 

(8)  classification  -  primitive  instauice-of  type; 

^3)  grouping  -  individual  contains  individual. 

The  other  relationships  are  unique  to  communication: 


-  23  - 


(4)  primitive  owns  primitive; 

(5)  address  connected-to  address; 

(6)  role  located-at  address; 

(7)  primitive  reachaWe-from  primitive; 

(8)  role  type  read  message  type; 

(9)  role  type  send  message  type; 

(10)  role  type  create  message  type; 

(11)  role  type  destroy  message  type; 

(12)  role  type  copy  message  type; 

(13)  role  type  modify  message  type. 

The  last  six  relationships  express  access  rights  of  roles  to  messages  -  read, 
create,  destroy,  copy,  modify  and  send.  Rights  are  specified  as  part  of  the  role 
and  message  type  definitions. 

The  type  definition  language  is  used  to  specify  the  properties  and  access 
rights  of  members  of  the  types.  The  definitions  also  constrain  the  relationships. 
The  manipuLation  operations  are  used  to  create,  copy,  select,  destroy  and 
modify  primitives  and  relationships.  The  circulation  operations  are  used  to 
change  the  ownership  of  messages.  We  explicitly  separate  the  operations  into 
different  categories  -  those  that  manage  the  messages  (performed  within  the 
context  of  a  role)  and  those  that  communicate  messages  (performed  within  the 
context  of  an  address).  The  predicate  language  allows  individuals  to  be  specified 
by  their  semantic  properties.  Control  structures  are  used  to  build  procedures. 
We  embed  circulation  primitives  and  the  predicate  language  in  control  struc¬ 
tures  to  get  routing  procedures,  and  we  can  embed  manipulation  primitives  and 
the  predicate  language  in  control  structures  to  get  communication  base  pro¬ 
cedures. 

Conceptually,  users  communicate  by  placing  messeiges  in  a  communica¬ 
tion  base.  Messages  can  also  be  stored  in  the  communication  base  for  future 
communication.  Agents,  which  can  be  users  or  processes  acting  on  the  users’ 
behalf,  interact  with  the  communication  base  when  they  take  on,  or  "play"  one 
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of  the  designated  roles  in  the  system.  An  agent  can  play  several  roles  (but  only 
one  at  a  time)  and  a  role  can  be  played  by  several  agents.  We  assume  there  is 
some  authorization  mechanism  outside  the  model  to  decide  the  roles  a  particu¬ 
lar  agent  is  to  be  allowed  to  play. 

The  set  of  roles  that  own  a  message  are  called  the  scope  of  the  message. 
These  roles  see  a  single  logical  message  and  all  changes  are  visible  to  all  own¬ 
ers.  Communication  is  carried  out  by  the  transfer,  or  sharing,  of  ownership  of 
messages.  Ownership  provides  a  very  general  representation  for  communica¬ 
tion.  There  is  a  notion  cf  shared  ownership  of  a  message.  The  communication  of 
a  message  does  not  necessarily  imply  the  relinquishing  of  authority  over  a  mes¬ 
sage.  We  can  also  represent  the  communication  in  both  message  systems  and 
data  base  systems  with  ownership.  To  model  communication  in  a  message  sys¬ 
tem  we  force  the  sender  of  a  message  to  relinquish  ownership  and  it  is 
transferred  to  the  recipient.  To  model  communication  in  a  data  base  system  we 
allow  modification  of  a  message  commonly  owned  by  a  set  of  users. 

We  examine  each  of  the  major  features  of  the  model  -  access  rights,  mes¬ 
sages,  roles,  addresses,  the  operations,  routing  procedures  and  triggers  -  in 
greater  detail.  We  conclude  with  a  formal  specification  of  the  semantics  of  the 
model. 

3.1 .  Access  Rights 

Access  rights  are  included  as  a  means  of  placing  constraints  on  the  roles' 
access  to  the  communication  base.  We  restrict  which  messages  a  particular 
role  can  access  and  how  the  role  is  able  to  operate  on  these  messages. 

There  are  six  access  rights  available  to  a  role.  These  correspond  to  the 
manipulation  operations.  A  role  must  possess  a  right  in  order  to  perform  the 
corresponding  operation(s)  on  a  peirticular  message.  The  create  right  allows  a 
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role  to  create  a  message  instance.  The  destroy  right  allows  a  role  to  destroy  a 
message  instance.  The  copy  right  allows  a  role  to  copy  a  message  instance.  The 
modify  right  allows  a  role  to  assert  and  remove  properties  of  a  message 
instance.  The  send  right  allows  a  role  to  submit  a  message  instance.  The  read 
right  allows  a  role  to  receive  and  retain  a  message  instance.  Without  the  read 
right  a  role  cannot  receive  a  message. 

The  access  rights  specification  is  part  of  both  the  role  type  and  the  mes¬ 
sage  type  definitions.  In  the  role  type,  access  rights  are  specified  to  message 
types.  All  instances  of  the  role  type  can  have  these  rights  to  all  instances  of  the 
named  message  type.  In  the  message  type,  access  rights  are  granted  to  role 
types.  All  instances  of  the  named  role  type  can  have  these  rights  to  instances  of 
the  message  type.  The  effective  set  of  rights  of  a  particular  role  to  a  particular 
message  is  the  intersection  of  the  rights  defined  in  the  corresponding  type 
definitions.  The  sender  and  receiver  are  forced  to  agree  on  access  to  a  message 
which  maximizes  security.  The  sender  can  anticipate  all  the  possible  types  of 
access  by  a  recipient. 

The  default  set  of  rights  is  assumed  to  be  empty,  i.e.  a  role  has  no  rights  to 
a  message  unless  explicitly  stated.  We  override  the  default  by  placing  lists  of 
rights  in  both  the  message  and  role  type  definitions.  The  system  administrator 
is  forced  to  consider  the  granting  of  access  rights  at  system  definition  This  is 
preferable  to  the  case  where  the  default  is  "all"  rights  since  any  errors  will  be 
in  the  omission  rather  than  the  inclusion  of  rights.  The  default  is  in  keeping 
with  our  emphasis  on  security. 

3.2.  Messages 

A  message  is  the  basic  unit  of  communication.  It  consists  of  a  system-wide 
identifier  and  some  contents.  .A  structure  can  be  imposed  on  the  contents.  For 
example,  a  business  form  can  be  thought  of  as  a  message  of  a  particular  type. 
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llowcver,  even  bit  strings  can  be  contents  of  a  message  without  any  added 
interpretation.  A  number  of  data  categories  can  be  defined  and  a  message 
declared  to  be  of  a  type  within  a  certain  category.  The  message  will  then  inherit 
the  structure,  constraints  and  operations  of  the  category.  The  structure  of  a 
message  can  be  dynamic  and  change  as  the  message  is  communicated  to  new 
roles.  The  definition  of  a  message  type  allows  us  to  capture  the  fact  that  a  lot  of 
the  communication  in  an  office  can  be  grouped  into  sets  with  similar  properties 
and  that  members  of  a  set  are  usually  processed  in  an  identical  manner. 

The  distinction  between  a  message’s  identifier  and  its  contents  is  an 
important  one.  We  must  be  able  to  recognize  and  trace  a  message  as  it  travels 
around  the  system.  The  contents  of  a  message  are  subject  to  change,  even  a 
change  of  format,  so  there  is  no  content  value (s)  stable  enough  to  uniquely 
identify  a  message.  By  creating  a  different  component  we  place  the  identifier 
outside  the  reach  of  the  agents  and  ensure  we  can  always  recognize  a  particu¬ 
lar  message  instance. 

The  contents  of  each  message  is  viewed  as  a  set  of  properties  We  classify 
messages  into  message  types  according  to  a  set  of  common  properties.  A  mes¬ 
sage  type  can  be  viewed  as  an  aggregate  of  properties.  The  message  type  defines 
a  structure  for  the  contents  and  messages  that  possess  this  structure  are 
instances  of  the  type.  For  example,  we  may  define  a  message  type  Memo  and 
instances  of  the  type  will  have  such  common  properties  as  Subject,  To,  Prom, 
and  so  on. 

A  message  t3^e  can  also  be  used  to  define  the  routing  within  the  MMS  for 
all  instances  of  that  type.  An  instance  of  the  routing  procedure  accompanies 
each  message  and  is  executed  at  each  address  that  receives  the  message.  We 
will  discuss  this  in  greater  detail  in  a  later  section. 

A  property  can  be  single-valued  or  multi-valued  (see  Gibbs  and  Tsichritzis 
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[GiTs63]  for  a  more  general  treatment).  The  values  of  properties  belong  to  sets 
known  as  domains.  For  example  the  domain  of  the  Subject  property  of  a  Memo 
could  be  a  set  of  strings.  We  will  just  deal  with  traditional  domains  like  string 
and  integer  in  our  discussion  but  office  systems  require  domains  such  as  text, 
audio  and  image. 

Different  message  types  may  be  related  by  generalization  and  specializa¬ 
tion  which  we  will  refer  to  by  the  is-a  relationship  [MyBWBO].  For  example,  the 
message  type  DatedMemo  can  be  considered  as  a  specialization  of  the  message 
type  Memo.  DatedMemo  is  structurally  more  refined  and  may  contain  the  addi¬ 
tional  property  Date  which  is  not  applicable  to  Memo.  This  type  interconnection 
allows  us  to  represent  the  message  categories  and  the  inheritance  of  proper¬ 
ties.  It  also  allows  messages  to  change  their  types  (actually  the  interpretation 
placed  on  the  messages  by  the  roles  changes).  These  changes  are  restricted  to 
paths  through  the  hierarchy.  A  message  can  be  considered  an  instance  of 
another  connected  type  as  long  as  it  has  the  required  properties.  Thus  t3q)e 
changes  are  limited  to  paths  in  the  is-a  hierarchy. 

Each  message  type  can  be  further  characterized  as  simple  or  aggregate 
Aggregate  messages  may  "contain"  other  messages.  This  mechanism  is  useful 
for  representing  such  things  as  dossiers,  multi-part  forms  or  several  docu¬ 
ments  "stapled"  together.  We  must  require  that  these  aggregate  messages  have 
their  own  unique  identifiers  separate  from  their  constituents’  identifiers.  We 
also  must  restrict  this  notion  of  containment  to  model  the  familiar  paper  office 
in  that  a  message  may  be  contained  by  only  a  single  aggregate.  This  will  avoid 
all  problems  of  sending  away  the  constituent  of  some  other  aggregate. 

A  message  type  definition  consists  of  five  sections:  properties,  constituents, 
mappings,  routing  and  constraints.  No  section  is  required  and  it  is  possible  to 
define  a  message  type  without  them.  In  this  case  we  would  have  messages  with 
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identifiers  but  no  contents. 

Message  identifiers  are  assigned  by  the  system  at  message  creation.  Every 
message  must  have  an  identifier  so  we  can  leave  it  out  as  a  property  of  a  mes¬ 
sage  type  and  represent  only  the  contents  in  the  message  t5^e  definitions.  We 
assume  message  identifiers  are  unique,  permanent  and  can  be  easily  obtained, 
such  as  with  the  reference  m.Id  where  m  is  a  variable  name  that  refers  to  a  par¬ 
ticular  message. 

For  example,  we  define  a  memo  message  type  in  Figure  3.1. 

define  message  type  Memo  begin 
properties: 

Memo  ^  Subject,  To,  Prom,  Text,  Cc+-, 

constraints: 

domain  of  Subject  is  string(lO): 
domain  of  To  is  string(l5); 
domain  of  fbom  is  string(15): 
domain  of  Text  is  string(lOO); 
domain  of  Cc  is  string(15): 

end 

Rgure  3.1:  Deftnition  of  Message  Type  Memo 

Note  that  the  Cb-^  means  Cc  is  multi-valued  and  each  value  will  be  out  of  the 
specified  domain. 

During  the  definition  of  message  types  it  is  possible  to  assert  that  one  mes¬ 
sage  type  is  a  specialization  of  another  by  using  the  statement 

Pis-a  Q 

where  P  and  Q  are  message  t5q>es.  If  we  define  the  message  type  DatedMemo  as 
in  Figure  3.2  and  state  that  DatedMemo  is-a  Memo  then  the  DatedMemo  message 
type  inherits  the  structure  of  Memo.  Any  instance  of  DatedMemo  -will  also  be  an 
Instance  of  Memo  and  possess  the  properties  of  both  DatedMemo  (Date)  and 
Memo  (Subject,  To,  FYom,  Text,  Cc). 
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define  message  type  DatedMemo  begin 
properties: 

DatedMemo  -»  Date, 
constraints: 

domain  of  Date  is  string(lO): 

end 


DatedMemo  is-a  Memo 


Rgure  3.2:  Definition  of  Message  Type  DatedMemo 


We  can  also  define  a  message  type  as  a  set  of  constituents.  For  instance  we 
can  define  a  dossier  as  in  Figure  3.3  to  contain  a  set  of  memos. 


define  messaige  type  Dossier  begin 
properties: 

Dossier  -*  Title-, 
constituents: 

Dossier  -»  Content s+-, 

mappings: 

Containedin:  Contents  ->  Dossier] 
Contains:  Dossier  ->  Contents] 
Kept  With:  Contents  -»  Contents] 

constraints: 

domain  of  Contents  is  Memo] 
domain  of  Title  is  string(25): 

end 


Figure  3.3:  Definition  of  Message  Type  Dossier 

Dossier  has  the  constituent  Contents  which  is  a  set  of  instances  of  Memo.  The 
mappings  section  defines  the  three  mappings  Containedin  maps  instances  of 
Memo  to  the  instance  of  Dossier  that  contains  them.  Contains  maps  a  Dossi,er  to 
the  set  of  Memos  it  contains.  KeptWiih  maps  a  Memo  to  the  set  of  other  Memos 
kept  with  it  in  the  same  Dossier. 

We  access  different  properties  and  constituents  by  chaining  together 
instance  names,  mapping  names,  property  names  and  constituent  names.  For 
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example,  ml. Subject  refers  to  the  subject  of  memo  ml,  and 
Kept  With.ml.  Subject  refers  to  the  subjects  of  all  the  memos  kept  with  ml  in  a 
dossier. 

It  is  possible  to  specify  the  access  rights  of  particular  role  t5^es  within  the 
constraints  section  of  a  message  type.  Thus  we  can  define  a  memo  type  Execu- 
tiveMemo  that  can  only  be  accessed  by  president  and  vice-president  roles.  ITie 
definition  in  Figure  3.4  is  a  specialization  of  the  message  type  Memo.  Instances 
of  EkecutiveMemo  will  have  all  the  properties  of  Memo  and  access  to  these 
instances  is  restricted  to  roles  of  the  types  VicePresident  and  President.  The 
"include(all)’'  means  that  the  rights  to  read,  write  and  send  are  all  granted  to 
the  roles. 

define  message  type  Executive  Memo  begin 
constraints: 

for  {Vice President,  President) 

include  (all); 

end 

Executive  Memo  is-a  Memo 

Figure  3.4;  Definition  of  Message  Type  Executive  Memo 

3.3.  Itolcs 

The  concept  of  a  role  is  taken  from  the  theatrical  context  where  a  role  is 
defined  to  be  a  part  played  by  an  actor  on  a  stage.  In  general,  a  role  is  a  defined 
behavioural  pattern  which  may  be  assumed  by  entities  of  different  kinds.  This 
notion  of  a  role  is  identical  to  that  of  Bachman  and  Daya  [BaDa77].  They  intro¬ 
duced  the  role  concept  to  data  models  as  a  means  of  characterizing  an  entity. 
In  previous  data  models,  all  the  aspects  of  a  real  world  entity  were  represented 
by  a  single  record.  The  role  data  model  describes  an  entity  in  terms  of  the  one 
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or  more  roles  it  plays  in  the  real  world.  For  example,  a  person  may  play  the 
roles  student,  employee,  customer,  and  so  on. 

There  is  a  many-to-many  relationship  between  role  types  and  entity  t3^es 
The  term  role  type  means  the  prototype  of  a  class  of  roles  with  similar  proper¬ 
ties.  The  term  entity  type  means  the  prototype  of  a  class  of  entities  character¬ 
ized  by  their  capability  to  play  the  same  roles.  The  members  of  role  classes 
and  entity  classes  are  non-overlapping. 

In  our  work,  the  concept  of  a  role  is  used  to  characterize  agents’  access  to 
the  communication  base.  Each  role  has  access  to  a  subset  of  the  messages  in 
the  communication  base,  namely  those  messages  owned  by  that  role.  By  play¬ 
ing  a  role,  an  agent  gains  access  to  those  messages  local  to  the  role.  There  is  a 
many-to-many  relationship  between  roles  and  agents.  A  role  can  be  played  by 
several  agents  and  an  agent  can  play  several  roles, 

Within  the  context  of  a  message  management  system,  we  define  a  role  to 
be  a  uniquely  identihabie  entity  within  an  office  or  organization  that  sends  or 
receives  information.  A  role  can  correspond  to  a  person  -  every  user  plays  the 
role  of  himself  /'herself  A  role  can  correspond  to  a  group,  such  as  "Students"  or 
"Employees".  Finally,  a  role  can  correspond  to  an  office  function,  which  is  a 
definable  set  of  responsibilities  and  actions  within  an  office  or  organization.  For 
example,  office  function  roles  can  be  "Sales  Manager"  or  "Instructor  of  CSC434", 
or  a  "system  sender"  which  represents  entities  such  as  printers,  file  servers  or  a 
waste  basket  for  discarded  messages. 

We  identify  three  cases  of  ownership  within  a  MMS.  If  a  message  is  associ¬ 
ated  with  a  single  role  we  say  that  the  ownersliip  is  private.  If  a  message  is  asso¬ 
ciated  with  two  or  more  roles  we  say  that  the  ownership  is  shared.  In  this  case 
there  is  one  "logical"  message  and  the  changes  made  by  any  of  the  roles  are 
automatically  visible  to  all  the  other  owners.  The  final  ease  is  called  common 
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ownership.  Independent  copies,  i.e,  the  same  contents  but  different  identifiers, 
are  associated  with  two  or  more  roles  and  the  changes  made  by  any  of  the  roles 
apply  only  to  their  own  copies.  We  assume  that  every  message  must  be  owned 
by  one  or  more  roles  as  long  as  it  is  in  the  communication  base.  Otherwise  the 
message  would  not  be  accessible, 

The  notion  of  ownership  places  tighter  restrictions  on  the  messages  acces¬ 
sible  to  a  role  compared  with  a  subschema  in  a  DBMS.  A  subschema  gives  a 
static  definition  of  the  properties  an  entity  must  have  to  be  accessible  from  the 
subschema,  Any  entity  that  has  these  properties  is  automatically  available  to 
users  of  the  subschema.  Ownership  means  that  a  message  must  be  explicitly 
made  available  to  a  role  either  by  creation  or  by  reception  of  the  message  from 
another  role  as  well  as  satisfying  the  properties  set  out  in  the  MMS  definition. 

The  major  purpose  of  a  role  is  to  map  a  set  of  agents  (those  agents  that  can 
play  the  role)  to  a  subset  of  all  the  messages  in  the  communication  base, 
namely  those  messages  accessible  to,  or  "owned  by"  the  role  Agents  are  not 
part  of  the  communication  base.  Only  by  playing  a  role  do  they  gain  access  to 
messages. 

The  operations  of  adding  or  deleting  a  role  and  of  allowing  or  disallowing  an 
agent  to  play  a  particular  role  should  be  restricted  to  a  communication  base 
administrator  [WooR3],  These  operations  force  drastic  changes  to  the  definition 
of  the  MMS  and  should  not  be  available  to  users 

Roles  that  share  common  properties  and  common  access  rights  can  be 
gi'ouped  into  rule  types  Role  types  can  be  related  by  generalization  and  special¬ 
ization  (is-a).  For  example  the  role  type  President  can  be  considered  a  speciali¬ 
zation  of  the  role  type  Executive  Officer.  President  may  have  additional  proper¬ 
ties  or  access  rights.  An  instemce  of  President  is  also  an  instance  of 
Executive  Officer  and  inherits  properties  and  access  rights  from  it.  Recall  that 
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we  assume  no  access  rights  to  be  the  default.  We  specialize  on  the  access  rights 
of  a  role  type  by  adding  access  rights  in  the  same  manner  we  specialize  the 
contents  of  a  message  type  by  adding  properties. 

Roles  and  messages  are  related  by  ownership.  We  say  that  if  a  role  R’owns  a 
message  m,  or  R  awns  m,  then  Rh&s  access  to  that  message  (determined  by  Rs 
rights  to  the  type  of  m).  Roles  can  also  be  related  by  owns.  We  say  that  if  Pawns 
Q,  where  P  and  Q  are  roles,  then  every  message  accessible  to  Q  is  also  accessi¬ 
ble  to  P.  We  assume  Pmust  have  its  own  access  rights  to  the  messages  owned 
by  Q.  A  role  gains  ownership  of  a  message  either  explicitly  by  creating,  receiv¬ 
ing  or  copying  the  message,  or  implicitly  when  some  other  role  it  owns  in  turn 
gains  ownership  of  that  message.  The  owns  relationship  between  roles  is  esta¬ 
blished  at  system  definition. 

We  define  role  types  in  a  similar  manner  as  message  types.  We  specify  two 
sections:  properties  and  constraints.  It  does  not  make  sense  to  define  a  role 
type  without  at  least  a  property  to  identify  the  individual  roles.  A  role  type 
without  a  constraints  section  means  that  all  its  instances  have  no  access 
rights.  A  definition  of  the  role  type  Executive  Officer  is  shown  in  Figure  3.5. 

define  role  type  Executive  Officer  begin 
properties; 

Executive  Officer  -*  Title-, 

constraints; 

for  {Memo')  include  (all); 

for  {Executive Memo)  include  (read); 

end 

figure  3.5:  Definition  of  Role  Type  Executive  Officer 

We  assert  that  the  role  type  President  (shown  in  Figure  3.6)  is  a  specialization 
of  the  role  type  Executive  Officer  by  stating  President  is-a  Executive  Officer. 
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Similarly  if  p  is  an  instance  of  Frasident  and  e  is  an  instance  of  Executive Offix^er 
we  can  assert  thatp  owns  e.  Thus  p  will  have  access  to  all  the  messages  of  e. 


define  role  type  President  begin 
constraints: 
for  {Executive  Memo) 

include  (create, modify, send): 


end 

President  is-a  Executive  Officer 

figure  3.6:  Definition  of  Role  Type  President 

3.4.  Addresses 

An  address  is  a  logical  unit.  It  provides  a  context  for  performing  routing 
decisions.  Addresses  are  connected  mto  a  network  that  represents  the  distribu¬ 
tion  of  the  routing  logic.  The  network  carries  out  the  circulation  of  messages 
within  the  communication  base. 

There  are  two  basic  kinds  of  addresses:  routing  addresses  and  mail 
addresses  (we  can  use  the  is-a  relationship  to  specialize  from  these  t5^es). 
Routing  addresses  can  never  ot^iginate  or  keep  messages,  only  forward  them. 
Mail  addresses  can  originpAte  and  keep  messages  as  well  as  forward  them.  The 
routing  addresses  provide  flexibility  in  the  evaluation  of  the  scope.  For  exam¬ 
ple,  an  addressing  scheme  could  be  constructed  with  a  routing  address  that 
handles  all  messages  for  a  group  of  addresses,  say  those  addresses  for  a  depart¬ 
ment,  and  routes  the  messages  based  on  their  contents  to  the  appropriate 
address  within  the  group.  Ah  addresses  outside  the  group  only  have  to  know  the 
single  routing  address  Mail  addresses  are  the  targets  of  messages.  Each  mail 
address  corresponds  to  a  role-agent  pair.  Messages  sent  to  a  particular  role  are 
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logically  routed  to  the  set  of  mail  addresses  that  correspond  to  all  the  agents 
playing  that  role.  The  relationship  located-at  associates  mail  addresses  to  roles. 
We  assume  that  if  a  message  is  delivered  to  one  role-agent  pair  then  it  is 
delivered  to  all  other  mail  addresses  corresponding  to  that  role. 

The  network  of  addresses  is  defined  by  the  set  of  connections  for  each 
address.  Given  two  addresses  A  and  B.  we  say  A  connected-to  B  if  A  knows  about 
B  and  is  able  to  send  messages  to  it.  We  assume  the  connections  are  directed. 

The  concepts  of  roles  and  addresses  provide  flexibility  in  assigning  users  to 
physical  locations.  Communication  is  between  roles  rather  than  between  partic¬ 
ular  users.  The  routing  and  delivery  of  messages  is  not  disrupted  if  people 
change  jobs  or  the  composition  of  groups  change.  Roles  also  reflect  the  fact 
that  often  individuals  perform  several  tasks  and  have  different  communication 
sets  for  each  of  the  tasks.  Addresses  are  logical  so  users  changing  their  physical 
locations  will  not  force  changes  to  the  routing  logic  of  the  system.  Only  the 
mapping  between  addresses  and  physical  locations  needs  to  change.  The  mes¬ 
sage  routing  carried  on  in  the  addressing  scheme  is  transparent  to  the  users  of 
the  ccmrnuni cation  base.  The  routing  can  be  implemented  in  a  variety  of  ways 
by  adding /deleting  routing  addresses  and  changes  can  be  made  without 
affecting  the  users.  A  role  also  defines  the  access  allowed  to  agents  playing  that 
role.  Role  definitions  therefore  reflect  the  security  desired  of  the  system. 

A  message  routing  through  the  netw'-ork  is  ■•..eoomplished  by  a  set  of  routing 
■procedure  evecutions.  A  routing  procedure  is  executed  at  each  address  visited 
by  a  message  while  in  circulation.  The  routing  procedure  definition  consists  of 
circulation  operations  within  a  control  structure  The  definition  can  appear  in 
an  adcires''  ■yr)e  or  a  message  type. 

We  UoC  the  term  addresszng  scheme  to  refer  lo  that  part  of  the  model  con¬ 
cerned  explicitly  with  the  circulation  and  delivery  of  messages.  This  will 


-36- 


include  the  logical  network  of  addresses,  the  messages  and  the  address  and 
message  t3^e  definitions,  Tsichritzis  [Tsic83]  defines  an  addressing  scheme  as  a 
way  of  specifying  and  interpreting  information  on  messages  that  eventually 
brings  them  to  the  attention  of  the  proper  recipients.  Addressing  schemes  are 
central  to  the  representation  of  communication  in  MMS’s  and  are  examined  in  a 
following  chapter. 

The  definition  of  an  address  type  can  contain  three  sections:  properties, 
routing  and  constraints.  Only  the  properties  section  must  be  there  and  must 
contain  an  address  identifier.  An  instance  of  an  address  type  has  the  properties 
of  the  type  and  executes  an  instance  of  the  specified  routing  procedure  for  all 
incoming  messages.  The  two  basic  address  types  are  Mail  and  Routing 
addresses.  An  example  of  an  address  type  is  shown  in  Figure  3,7,  It  defines  a  set 
of  simple  routing  addresses  that  broadcast  any  incoming  message  to  all  the 
addresses  to  which  they  are  connected.  The  special  variable  current  refers  to 
the  message  currently  being  processed.  The  multivalued  property  Connect  is 
initialized  to  the  set  of  connected  addresses. 
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define  address  type  Routing  begin 
properties: 

Routing  -»  Identifier  .Connect +', 

constraints: 

domain  of  Identifier  is  string(lO); 
domain  of  Connect  is  3tring(l0); 
routing: 

variable  B  string(l  0); 
case  0  begin; 

for  each  5* in  Connect  begin; 

share  current  with  B-, 
end; 

drop  current; 
end; 

end; 


figure  3.7:  Definition  of  Address  Type  Routing 


3.5.  Operations 

The  manipulation  operations  are  initiated  by  an  agent  playing  a  role.  The 
role  supplies  the  context  for  the  operation,  i.e  the  effect  is  limited  to  those 
messages  owned  by  the  role  and  the  operation  must  be  allowed  by  the  role’s 
access  rights.  The  operations  create,  copy,  destroy  and  submit  cause  changes  to 
the  ownership  of  messages.  The  assert,  remove  eind  query  operations  do  not 
change  message  ownership. 

The  create  operation  creates  a  new  instance  of  a  message  type  and  places 
it  in  the  communication  base.  For  instance, 

create  a  Memo  is  ml, 

creates  a  new  instance  of  the  Memo  message  type.  At  creation  the  message  is 
bound  to  its  identifier  and  remains  bound  to  it  until  deleted  from  the  communi¬ 
cation  base.  The  message  is  also  bound  to  a  Local  name,  such  as  ml.  This  is  a 
convenient  reference  for  the  agent  and  is  temporary.  The  local  name  acts  as  a 
pointer  and  can  be  bound  to  another  message  just  as  a  variable  name  is  bound 
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Lo  different  values  The  message  identifier  is  system-assigned  and  will  likely  be 
cumbersome  for  users.  At  creation  single-value  properties  and  constituents 
have  the  NULL  value;  multi -value  properties  and  constituents  are  the  empty 
set.  The  instance  created  is  owned  by  the  role  that  creates  it. 

The  copy  operation  creates  a  new  message  instance  with  its  own  identifier 
that  is  the  same  type  eind  has  the  same  contents  as  another  message.  The  copy 
is  owned  by  the  role  that  issues  the  command  For  example, 

copy  of  m  f  is  m2', 

creates  a  copy  of  the  message  referenced  by  ml  and  binds  it  to  the  local  name 
m2. 

The  destroy  operation,  which  is  written  as 

destroy  m2, 

has  two  cases.  First,  if  ownership  of  the  message  is  shared,  then  only  the  role 
issuing  the  destroy  loses  ownership  of  the  message.  Ownership  is  still  retained 
by  the  other  roles  and  the  message  remains  in  the  system.  Second,  if  ownership 
is  private,  then  the  message  is  removed  from  the  communication  base. 
Another  possibility  is  to  implement  the  destroy  as  a  transfer  to  a  special 
archival  role.  This  way  the  information  can  always  be  retrieved. 

The  assert  and  remove  operations  are  used  to  alter  the  property  and  con¬ 
stituent  values  of  messages.  Any  modifications  to  the  contents  of  a  message  are 
apparent  to  all  roles  that  share  ownership  of  that  message,  i.e.  all  roles  in  the 
scope  of  the  message.  Simple  properties  are  assigned  a  value  by  identifying  a 

message  (with  a  local  name),  a  property  and  a  value.  For  example, 

assert  ml  Subject  is  "Sales  Meeting"; 
assert  mi  Cb  is  "John"; 

The  remove  operation  assigns  NULL  to  single-value  properties  and  removes  a 
specific  value  in  a  set  for  multi-value  properties.  For  instance. 
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remove  m!.Su.bject, 
remove  ml.Cc  is  "John"; 

When  used  with  a  constituent,  assert  establishes  an  association  between  two 

messages.  For  example, 

create  a  Dossier  is  dB, 
assert  Contains. dS  is  mV, 

places  the  memo  ml  into  the  dossier  d2.  The  remove  operation  is  used  to  elim¬ 
inate  the  association. 

In  most  message  system  applications  the  majority  of  queries  will  be 
searches  for  messages  with  particular  property  values.  There  are  other  possibil¬ 
ities,  such  as  projection,  but  these  will  not  be  considered  here.  A  selection 
binds  a  local  name  to  a  subset  of  the  messages  local  to  the  role  issuing  the 
query.  For  example  to  find  edl  memos  concerning  the  subject  "Tax  Deadline"  we 
would  write 

select  tax  is  Memo  where  Subject  =  "Tax  Deadline"; 
and  to  find  all  memos  in  the  Sales  dossier  concerning  "Customer  X"  we  would 

specify 

select  mem  is  Contents: Sales  where  Subject  =■  "Customer  X"; 

The  qualification  can  be  on  the  message  identifier  or  content  properties.  It  can 

compare  properties  to  constants  or  other  property  values,  match  a  pattern  of 

text  or  be  a  combination  of  these. 

The  circulation  operations  are  used  to  change  ownership  of  a  message  in 
circulation.  This  means  the  message  is  moved  through  the  address  network  and 
eventually  delivered  to  the  appropriate  set  of  addresses  and  their  correspond¬ 
ing  roles.  The  circulation  operations  are  issued  local  to  an  address  and  are  not 
available  to  the  roles.  A  message  is  placed  into  circulation  by  a  role  issuing  a 
submit  operation.  From  this  point  the  addressing  scheme  takes  over  and  "owns" 
the  message  until  it  is  removed  from  circulation  by  one  or  more  deliver  opera¬ 


tions. 
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The  submit  operation  specified  by 

submit  m  7; 

shares  ownership  of  the  specified  message  with  one  of  the  role's  associated 
addresses,  namely  the  address  for  the  active  agent.  The  message  is  effectively 
placed  into  circulation  and  can  be  routed  through  the  network  of  addresses  to  a 
set  of  destination  roles  determined  by  the  addressing  scheme.  We  assume  own¬ 
ership  is  retained  by  the  sender.  Another  option  would  be  to  assume  ownership 
is  transferred,  not  shared,  with  a  submit.  This  assumption  is  fine  for  the  tradi¬ 
tional  paper  office  where  only  one  person  can  "own"  a  piece  of  paper.  But  with 
electronic  mail  it  is  possible  for  more  than  one  person  to  access  the  same  logi¬ 
cal  message.  Sharing  of  ownership  is  the  more  general  case,  and  a  transfer  can 
be  accomplished  by  a  submit  and  a  destroy  in  our  framework.  A  third  option 
would  be  to  have  two  submit  operations  -  transfer  and  share  This  would  compli¬ 
cate  the  user  interface  and,  as  pointed  out  above,  transfer  is  a  special  case  of 
share. 

An  address  can  forward  a  message  to  another  address  connected  to  it.  The 
first  address  transfers  the  message  to  the  second  and  loses  ail  contact  with  it. 
The  operation  is  widtten 

forwctrd  m  to  ai; 

and  if  executed  local  to  the  address  aOthen  the  result  is  that  aOno  longer  owns 
m  and  al  owns  m. 

address  can  share  a  message  with  another  address  connected  to  it.  In 
this  case  the  first  address  retains  ownership  as  well  as  transferring  it.  This 
situation  would  not  be  possible  in  a  paper  office  but  is  realistic  with  electronic 
mail.  The  operation  is  written 

share  m  with  al, 

and  has  the  effect  that  al  now  owns  m. 
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An  address  can  deliver  a  message  which  we  interpret  as  the  message  reach¬ 
ing  one  of  its  targets  and  leaving  circulation  at  that  point  along  the  particular 
path  (a  message  can  travel  several  paths  of  the  network  simultaneously)  Thus 
the  corresponding  role  is  considered  part  of  the  scope  of  the  message  and  it 
obtains  ownership  of  the  message.  We  write  the  operation  as 

deliver  m; 

and  if  executed  local  to  address  aO  that  is  a  mail  address  for  role  r  then  loses 
ownership  of  m  and  r  gains  ownership  of  m. 

Finally  an  address  can  drop  a  message  which  means  the  message  leaves 
circulation  without  reaching  one  of  its  destinations.  We  represent  this  as 

drop  m; 

and  if  executed  at  address  aO  then  aO  loses  ownership  of  m. 

3.6.  Routing  Procedures 

The  most  important  use  of  the  control  structures  and  predicate  language 
(in  terms  of  communication)  is  in  the  specification  of  routing  procedures.  Rout¬ 
ing  procedures  can  be  specified  within  address  or  message  types.  We  will  discuss 
routing  procedures  associated  with  the  addresses  but  the  same  things  apply  for 
routing  procedures  associated  with  messages. 

Each  address  gets  an  instance  of  the  routing  procedure  defined  with  its 
address  type.  Messages  are  processed  one  at  a  time  at  each  address  and  the  pro¬ 
cedure  is  executed  for  each  message  that  arrives.  Only  one  execution  of  the 
procedure  can  exist  at  any  one  time  at  an  address  so  messages  are  queued  up 
and  wait  until  they  can  be  processed.  We  assume  "first-come-first-serve"  but 
other  priority  schemes  are  possible. 

Routing  procedures  can  have  a  set  of  ir.stan.ce  variable  declarations.  These 
variables  retain  their  values  between  executions.  All  other  variables  are  reini- 
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Lializec]  at  Ihc  start  of  every  execution.  Routing];  procedures  are  also  able  to 
access  all  local  messages,  not.  just  the  message  currently  being  processed.  We 
represent  this  set  by  an  array  of  an  instance  variable  type  refsrencp. 

The  basic  structure  of  a  routing  procedure  is  a  series  of  case  statements. 
A  case  'will  correspond  to  different  message  types  in  an  address  logic  scheme 
and  to  different  address  names  (or  sets  of  address  names)  in  a  message  logic 
scheme.  We  assume  that  if  a  message  satisfies  more  than  one  case  the  most 
specialized  type  will  be  used.  For  example  if  one  case  specifies  messages  of  type 
Memo  and  a  second  case  specifies  messages  of  type  DatedMemo.  the  second  case 
will  be  performed.  The  basic  programming  constructs  of  our  routing  language 
are  bounded  loops  -  for  referencing  a  set  of  connections,  values  of  a  multi¬ 
valued  property  or  constituents,  or  array  variables  -  if-then-else  statements, 
assignment  statements  (to  variables)  and  the  set  of  circulation  operations. 
Expressions  can  involve  properties,  types  and  constants.  The  usual  numeric 
operations  as  well  as  pattern-matching  and  set  membership  are  allowed.  A 
definition  of  our  routing  language  is  shown  in  Appendix  1.  The  choice  of  con¬ 
structs  is  discussed  in  Chapter  4  of  the  thesis.  Figures  3.8  and  3  9  show  exam¬ 
ples  of  routing  procedures. 

The  routing  procedure  in  Figure  3  8  demonstrates  the  use  of  instance  vari¬ 
ables  to  simulate  local  memory  for  an  address.  The  address  is  able  to  retain 
information  about  previously  received  messages  and  use  this  information  in 
making  its  routing  decisions.  Figure  3.9  shows  a  routing  procedure  that  coordi¬ 
nates  the  messages  it  receives.  It  waits  until  a  set  of  messages  have  arrived 
before  performing  the  routing.  The  instance  variable  save  of  type  reference  is 
used  to  keep  track  of  the  messages  being  coordinated 
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Instauice  vaolable  v  1  integer; 
begin; 

case  (type  is  Memo)  begin; 
if  {currenl.Subject  =  "Customer  Complaint") 

and  {v  1  <  5)  then 
forwaird  current  to  a2: 
vl  vl  +  1; 
end; 
else; 

drop  current; 
end; 
end; 


Rgure  3.8:  Example  Routing  Procedure 


instance  variable  co^iTl^  integer; 
instance  variable  save  (3)  reference; 
begin; 

case  (type  is  Memo)  begin; 
if  count  <  3  then 
count  count  +1; 
save  (count)  *-  eurrent; 
end; 
else; 

forward  current  to  a  ? ; 
forward  save(  1)  to  a  R. 
forward  save (8)  to  a R. 
forward  save  ^3^  to  a  7 ; 
count  <-  0; 
end; 
end; 
end; 


Figure  3.9:  Example  of  Routing  Procedure 


3.7.  Triggers 

We  noted  in  our  discussion  of  communication  in  OIS's  that  there  is  a  need 
for  constructs  to  perform  the  automatic  processing  of  messages.  The  OIS's  we 
examined  all  had  this  feature.  The  routing  procedures  of  the  last  section  han¬ 
dled  automatic  routing.  A  similar  feature  is  required  for  the  automatic 
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managemenL  of  messages.  We  introduce  triggers  into  the  model  to  handle  this 
need. 

Triggers  operate  in  the  same  manner  as  office  procedures  or  data  base 
alerters.  They  are  fired  when  a  particular  event  occurs,  in  our  case  an  access  of 
the  communication  base,  and  the  specified  actions  are  performed.  The  syntax 
we  use  is  similar  to  Gibbs  [GibbB3].  We  employ  triggers  mostly  as  a  means  to 
model  the  automatic  response  to  events.  Gibbs,  on  the  other  hand,  also  uses 
triggers  to  express  constraints  on  data.  Triggers  are  useful  to  model  such 
activities  as  generating  acknowledgements,  generating  notifications  or  check¬ 
ing  time  constraints  on  a  message,  for  example  how  long  has  a  message  been 
waiting  to  be  processed. 

A  trigger  is  local  to  a  role.  Any  notifications  generated  by  a  trigger  only  go 
out  to  agents  playing  that  role  and  any  actions  performed  by  the  trigger  are  on 
behalf  of  that  role.  Any  of  the  other  owners  of  a  message  are  not  involved.  A 
trigger  is  only  activated  when  those  messages  owned  by  the  associated  role  are 
accessed.  So  to  have  a  trigger  apply  to  all  owners  of  a  message  we  must  have  a 
separate  instance  of  that  trigger  associated  with  each  owner  and  the  set  of  the 
triggers  will  be  activated  together.  But  a  trigger  is  activated  if  any  of  the  own¬ 
ers  act  upon  the  message,  not  just  the  role  it  is  associated  with.  The  actions 
associated  with  a  trigger  are  performed  after  the  operation  that  activated  it. 

A  trigger  definition  consists  of  four  sections:  pattern,  condition, 
notification  and  action  The  pattern  section  is  mandatory  and  is  made  up  of  an 
activation  pattern  and  possibly  some  type  restrictions  on  the  messages 
specified  in  the  activation  pattern.  A  trigger  can  be  activated  by  the  execution 
of  the  manipulation  operations  -  create,  copy,  destroy,  assert,  remove,  select 
and  submit  -  and  the  deliver  operation.  The  effects  of  these  operations  are  all 
visible  to  the  roles,  or  the  operations  are  initiated  by  the  roles.  The  remaining 
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circulation  operations  only  take  place  within  the  addressing  scheme  and  are 
transparent  to  the  roles. 

The  pattern  section  consists  of  an  activation  pattern  and  possibly  some 
type  restrictions  on  message  variables  used  in  the  activation  pattern.  An 
activation  pattern  is  specified  at  the  beginning  of  the  pattern  section  and 
resembles  an  operation  Identifiers  preceded  by  a  "?"  may  appear  in  the  activa¬ 
tion  pattern.  These  are  bound  at  activation  and  can  be  referred  to  in  later  sec¬ 
tions  of  the  trigger. 

In  many  situations  it  is  only  necessary  to  activate  a  trigger  if  the  messages 
are  of  a  specific  type.  Extra  restrictions  indicating  whether  a  message  should, 
or  should  not,  be  of  a  particular  type  can  be  included.  Only  one  type  restriction 
may  appear  for  each  message  in  the  activation  pattern. 

Figures  3.10  and  3.11  show  two  example  pattern  sections.  The  pattern  in 
3.10  will  activate  its  trigger  whenever  a  message  of  the  type  ErecutiveMemo  is 
delivered.  The  pattern  in  Figure  3.11  will  activate  its  trigger  whenever  a  mes¬ 
sage  that  is  not  of  type  JanJcMail  is  delivered. 

pattern: 

deliver  ?m; 

message  type  of  m  is  Executive  Memo', 

figure  3.10:  Example  Pattern  Section 

pattern: 

deliver  ?m; 

message  type  of  m  is  not  Junk  Mail, 

Figure  3.11:  Example  Pattern  Section 

The  condition  section  can  be  used  to  express  restrictions  on  the  contents 
of  the  message  or  any  time  constraints  that  may  be  required.  The  conditions  on 
the  contents  are  expressed  in  the  same  syntax  as  the  conditions  for  the  where 
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clause  of  the  select  operation  The  most  obvious  use  of  time  constraints  is  to 
generate  a  reminder  or  perform  an  action  after  a  message  has  waited  a  certain 
length  of  time  to  be  processed.  Figure  3,12  shows  a  pattern  that  will  activate  a 
trigger  whenever  a  message  of  type  Memo  concerning  the  subject  'Tax  Dead¬ 
line"  is  placed  in  another  message  of  t5^e  Dossier. 


pattern: 

assert  Contains  is  ?2/; 
message  type  of  x  is  Dossier] 
message  type  of  y  is  Memo-, 
condition: 

y. Subject  -  "Tax  Deadline": 


figure  3.12:  Example  Condition  on  Message  Contents 
Figure  3.13  contains  a  pattern  that  activates  a  trigger  when  a  message  of 
type  UrgentMemo  is  delivered.  The  actions  or  notifications  associated  with  the 
trigger  are  suspended  and  only  performed  after  two  days.  Any  access  to  the 
message  m  by  the  role  controlling  the  trigger  will  deactivate  it  and  the  actions 
or  notifications  will  not  be  performed 


pattern: 

deliver  ?m; 

message  type  of  m  is  UrgentMemo] 
condition: 
response  is  2  days, 


figure  3.13:  Example  Condilion  on  Time 
The  notification  section  contains  an  alert  that  is  presented  to  the  agents 

pla)hng  the  role  that  controls  the  trigger  when  the  pattern  is  matched.  The 
action  section  contains  a  set  of  manipulation  actions  to  be  performed  when  the 
pattern  is  matched. 

Figure  3.14  contains  a  trigger  that  will  automatically  generate  ack¬ 
nowledgements  for  any  messages  of  t3^e  Memo  that  are  received. 
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define  trigger  Acknowledge  begin 
pattern: 
deliver  ?m; 

message  type  of  m  is  Memo-. 
action: 

create  a  Reply  is  mi ; 

assert  ml.  To  is  m.From\ 

assert  m  l.From  is  here.i?oZe7iame; 

assert  ml.  Text  is  "Received  your  memo"; 

submit  ml\ 

end 


figure  3.14:  Acknowledge  Trigger 

The  trigger  in  Figure  3.15  will  generate  a  reminder  for  any  messages  that  have 
not  been  handled  within  three  days  of  arriving. 

define  trigger  Reminder  begin 
pattern: 

deliver  ?m: 
condition: 

response  is  3  days] 
notification: 

alert:  "message"  m.Id  "waiting  3  days"; 

end 


figure  3.15:  Reminder  Trigger 

3.6.  Formal  Semantics  of  the  MMS  Model 

The  complexity  of  our  model  does  not  allow  us  to  simply  rely  on  informal 
descriptions  of  the  structure  and  operations.  We  require  a  formal  language  in 
order  to  give  an  unambiguous  specification  of  the  possible  states  of  the  com¬ 
munication  space  and  how  the  operations  affect  these  states. 

We  have  stated  that  ownership  is  the  basic  relationship  used  to  describe 
communication.  An  act  of  communication  is  represented  by  a  change  in  the 
ownership  of  a  message.  A  natural  description  of  ownership  is  in  terms  of 
admissible  states  for  the  communication  space  and  the  before  and  after  states 
of  the  operations.  'ITiis  method  of  formal  specification  has  been  applied  to  data 
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models  [SmSm79,BoWo81  ]  and  to  an  office  data  model  [Gibb83].  We  restrict  our 
attention  to  the  formal  specification  of  the  communication  semantics  of  the 
model.  The  other  aspects  of  the  semantics  are  treated  by  Gibbs  [Gibb83] 

We  first  list  a  number  of  axioms  that  constrain  the  communication  space. 
A  state  of  the  communication  space  will  be  consistent  if  it  satisfies  these 
axioms.  We  next  specify  the  communication  semantics  of  the  operations  in 
terms  of  the  before  and  after  states  of  the  communication  space.  This  frame¬ 
work  can  also  be  used  to  formally  express  explicit  constraints  on  communica¬ 
tion.  We  do  this  in  the  next  chapter  for  the  properties  of  completeness,  serial- 
izability  and  time-independence. 

3.B.I.  Axiomatizatioa 

We  first  define  the  following  predicate  symbols  that  will  be  used  to  express 
the  axioms  of  our  MMS  model: 

M,{xYx  is  a  simple  message  type, 

Ma{x)\  X  is  an  aggregate  message  t)^e, 

R{xy.  is  a  role  type, 

A{x)  X  is  an  address  type, 

I{x):  X  is  an  instance, 

l{x  ,y):  X  is  an  instance  of  y , 

a{x  ,y)Xype  x  is  a  specialization  of  type  y , 

ic{x,y)‘.  X  is  connected  to  y , 

p{x ,y):  role  x  is  located  at  address  y , 

u{x  ,y)  :  X  owns  y , 

n(a:,y);  message  type  x  has  a  constituent  message  type  y , 
n{x  ,y)-.  X  has  a  constituent  y, 

a{x,y):  role  type  x  has  read  access  to  message  type  y . 

^{x,y):  role  type  x  has  send  access  to  message  type  y. 
y{x,y):  role  type  x  has  create  access  to  message  type  y, 
x{x,y):  role  type  x  has  copy  access  to  message  type  y, 

6{x,y).  role  type  x  has  destroy  access  to  message  type  y, 

7}{x,y)-.  role  type  x  has  modify  access  to  message  t5rpe  y, 
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li{x,y).  X  is  reachable  from  y. 

We  also  define  the  following  abbreviations: 


M{x)  =  Ms{x)\/Ma{x), 

4i(x)  =  {3y){t{x,y)/\M{y)), 

Ir{x)  =  (3y)(t(x.'i/)Ai?(|/)). 

laix)  =  {3y)[L{x  .y)/\A{y)). 

T{x)  =  M{x)\'R{x)\'A{x), 

T{x,y)  =  (x{x,y)'^^{x,y)\/y{x,y)'^{x,y)\/6{x.y)\/7){x,y). 

where  these  abbreviations  have  the  following  meanings: 

4j(x):  X  is  a  message, 

4(x):  X  is  a  role, 

4(x):  X  is  an  address. 

Mix).  X  is  a  message  type, 

T{x)\  X  is  a  type, 

t{x  ,y).  role  t)^e  x  has  access  rights  to  message  type  y. 

The  axioms  are  stated  using  first-order  predicate  calculus.  The  prefix  "(x)" 
to  an  axiom  is  read  "for  all  x".  The  first  axiom  states  that  message  types,  role 
types,  address  types  and  instances  are  totally  inclusive  in  the  communication 
space. 

{x){M{x)\/R{x)\/A{x)\/I{x))  A1 

The  next  four  axioms  require  that  message  types,  role  types,  address  types  and 
instances  are  mutually  exclusive: 


(x)(A/(x)  3  ~i?(x)  A~>l(x)  A~/(x))  A2 

{x){R{x)  3  (x)  A~^(x)  A~/(x))  A3 

(x)(y4(x)  3  ~Af(x)A~it’(x) A~/(x))  A4 

(x)(/(x)  3  ~Af(x) A~i?(x)A~A(x))  A5 

Messages,  roles  and  addresses  must  also  be  mutually  exclusive. 

^  ~4(^)^~4(^))  A.6 

{x){Ir{x)  3  ~4n(x)A~4(x))  A7 

(x)(4(x)  3  ~/-^(x).a-4(x))  A8 

Message  types  are  either  simple  or  aggregate  but  not  both. 
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{x){M,{x)  ^~Ma{x))  A9 

(x)(iW;,(x)  3  AlO 

The  next  set  of  axioms  ensure  that  the  predicates  t,  a,  k,  cj.  p,  FI,  n,  a,  /3,  7 
and  pL  are  defined  on  the  appropriate  sets  by  relating  them  to  the  single  place 
predicates. 

ix){y){i{x  .y)  3  {Im{x)'^M{y))\/{Ir{x)/\R{y))\/ 

(4(x)a^(^)))  All 

(x)(t/)(ct(x,-i/)  3  {{Ms{x)/\Ms{y))\y{Ma{x)A.Ma{y)h^ 

{R{x)/\R{y))\/{A{x)^A{y))))  A12 

{x){y){u{x  ,y)  J  {3  v'){3  w){{R{v)/\M{w)'^t{v  ,w)y\i{x  ,v)^L{y  ,'w))\/ 

{Ir {X )  A/^ {y))\'{Ia  {x )  A/^  {y ))))  A1 3 

{x){y){ic{x  .y)  3  {Ia{^)^Ia{y)))  A14 

{^){y){p{^ >y)  ^  (4- (^) ^4 (?/)))  ai5 

(x)(i/)(n(x.'j/)  3  {Ma{x)^M{y)))  A16 

(x)(y)(7T(x,'y)  :y  {3v){3'w){Ma{v)'^M{'w)^i{x ,v)^i{y ,\u)))  A17 

(x)(^)(a(x,i/)  3  (it’(x)A^(y)))  AIB 

(^)(l/)(/^(3^.y)  ^  (^U)^^(y)))  A19 

(^)(v)(7(^.'y)  ^  A20 

{x){y){x{''^.y)  ^  i^{^)'^^{y)))  A2i 

(x)(y)((5(x,'y)  3  {R{x)/\M{y)))  A22 

ix){y){'n{^  <y)  ^  {fi{^)^M{y)))  A23 

{x){y){pi{x  ,y)  3  ((4(^)^4(iy)M4(a:)A4(i/))))  A24 

A  message  can  be  a  constituent  of  at  most  one  aggregate  message, 

(x)(x’)(i/)((4i(a:)A4i(x’)A(/^(y)A 

Tr(x,y  )a7t(x ',!/))  3  x=x')  A25 

The  is-a  relationship  is  reflexive,  transitive  and  not  symmetric. 

A26 

,t")  3  G{t,t"))  A27 

Dt=t')  .A28 

The  extension  of  a  type  is  a  subset  of  the  extensions  of  its  super-types. 


That  is,  an  instance  of  a  type  is  also  an  instance  of  all  the  generalizations  of 
that  type. 
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The  access  rights  to  an  aggregate  message  type  must  be  accompanied  by 
access  rights  to  all  the  constituent  types, 

(r)(0((K(0A/r(r)AT(7-,0)  A30 

Access  rights  are  inherited  via  the  is-a  relationship.  If  one  role  type  is  a  special¬ 
ization  of  another,  then  the  first  type  inherits  the  access  rights  of  the  second, 

{x){y){z){{R{x).^R{y)/\M{z)/\T{y  .z)A.a{x  ,y))  3t(x,z))  A31 

If  a  role  type  has  access  rights  to  a  message  type  it  also  has  the  same  access 
rights  to  a  specialization  of  that  message  type  (it  may  have  more  if  there  are 
rights  explicitly  for  the  specialization). 

{x){y){z){{R{x)^M{y)'^M{z)'\T{x  .y)^a{z  ,y))  d  t{x  .z))  432 

The  conoected-to  relationship  is  reflexive. 

(a)(ic(a.a))  A33 

The  next  four  axioms  deal  with  the  owns  relationship.  Ownership  is  transi¬ 
tive  and  reflexive  among  roles. 

(7-)(r')(r'')(4.(r)A4(r’)A4(r'')Aw(r,7-')A 

cj(r',r'’)  3  w(r.r"))  434 

(r)(w(r,r))  435 

4ccess  rights  are  not  inherited  via  ownership.  So  a  role  can  own  messages 
owned  by  another  role  only  if  it  has  its  own  access  rights  to  the  appropriate 
types.  This  axiom  is  true  for  the  case  where  t"  may  be  a  generalization  of  the 
t57pe  of  m  seen  by  r', 

(r)(r’)(m)((3  0(3  t’){3  t")iR{t)^R{t')^M{t")/M{r  ,t')^ 

^(m,^'')Ar(^  ,r')A(u(r  ,r')Acj(r',7n)  Dw(r,m)))  A36 

Ownership  of  an  aggregate  means  ownership  of  all  its  constituents.  But  the 
individual  ownership  of  one  of  the  constituents  does  not  necessarily  imply  own¬ 
ership  of  the  aggregate. 
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{r){m){{3  ,t)^o{r  .m)  D  (m')(rr(m,m')Aa>(r  ,m'))))  A37 

The  reachable  relationship  serves  two  purposes.  First,  it  defines  the  paths 
within  the  addressing  scheme.  One  address  is  reachable  from  another  if  there  is 
a  path  of  connections  from  the  second  address  to  the  first.  We  define  reachabil¬ 
ity  recursively. 

{3  z){fx{z  .y)/^K{z  .x)))  D  fi{x  .y)  A38 

The  reachable  relationship  can  also  exist  between  two  roles  and  indicates  that 

the  second  role  is  potentially  a  member  of  the  scope  of  all  messages  sent  by  the 
first  role.  One  role  is  reachable  from  another  if  there  is  a  path  in  the  addressing 
scheme  from  each  mail  address  corresponding  to  the  second  role  to  each  mail 
address  of  the  first  role.  This  constraint  is  necessary  because  we  cannot  have 
messages  going  to  only  a  subset  of  the  agents  playing  a  role,  nor  can  we  have 
only  a  subset  of  the  agents  playing  a  role  able  to  reach  some  other  role. 

(a: )  (y )  ( 4- (^ )  A/r  (y )  )  (tij  )  ( 4  )  a4  (ti; )  A 

p{x,v)A^{y,w)A.fx{v.w)))Dfx{x,y)  A39 

3.6.2.  Semantics  of  Manipulation  and  Circulation  Operations 

We  now  state  the  semantics  of  the  operations  in  the  MMS  model.  Again,  we 
are  only  concerned  with  the  operations  as  they  affect  the  state  of  the  communi¬ 
cation  space.  We  will  not  deal  with  the  query  operation  or  the  assert  and  remove 
operations  for  properties  since  they  have  no  effect  on  ownership.  We  specify  the 
communication  space  in  terms  of  the  following  sets  that  correspond  to  the 
predicates  defined  previously:  M,  M^.  Mg.  A,  R,  7,  4.  4.  o',  c5,  Ic,  Jl,  p,  H,  n,  a, 

y.  X,  5,  V  t.  We  will  let  U correspond  to  the  set  of  all  individuals,  that  is 

U  =  M  u  A  u  R  u  7. 

The  operations  take  a  state  of  the  communication  space  C  and  produce  a 
new  state  C.  In  the  following  specifications,  sets  without  a  '  (prime)  refer  to  C 
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and  sets  with  it  refer  to  C'.  We  assume  a  primed  set  to  be  the  same  as  the  origi¬ 
nal  set  unless  indicated  otherwise.  The  exception  to  this  fact  is  U  since  a 
change  to  any  of  M,  A,R  orl  implies  a  change  to  U. 

A  role  that  creates  a  message  must  have  create  access  to  the  appropriate 
type.  This  will  be  true  if  create  is  specified  in  both  the  role  and  message  type 
definitions.  The  role  owns  the  message  after  execution  of  the  create. 

creaia  [m  ,t.  Q,r  ,t \]'  C  >  C 
let 

S=\t  I  itQ,t)edl 
preconditions 
m 

T  e/_ 

then 

r  -  I  'j  \m\ 

T  -Tu  lito.t)  i 

u'  =  o  u  \{r,Ta)l 

A  role  that  copies  a  message  must  have  copy  access  to  the  message's  type 
and  own  the  original  message.  After  execution  of  the  operation  the  role  owns 
the  copy. 

copy  iJ:  C  ^  C 

let 

S=\t 

preconditions 

U 

to^M_ 

r€f_ 

t^^R 

(r  ,mo)ew 
then 

r  =  I  u  \m^l 
r  =  lu  I  tcSi 

w'  =  w  u  ^(r ,m,)! 

The  specification  of  the  destroy  operation  has  two  cases.  The  first 
expresses  the  state  changes  for  private  ownership.  We  assume  a  destroy  cannot 
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be  done  on  an  aggregate  (privately  owned)  until  all  the  constituents  are 
removed,  A  role  must  have  destroy  access  to  the  message. 


destroy  C  ->  C 

let 

S=\t  \ 

K  =  [c  \  {7n.c)cn] 
preconditions 
m^I_ 

(mdo)^ 

rel 

{r.t^T 

t^eMa^K  =  d) 

(r  ,m)e5> 
then 

r  =  r  -  \m\ 

T  =  T  -  !  t^iS] 

o'  =  o  -  {{r  ,7n)\ 

The  second  case  of  the  destroy  operation  is  shared  ownership.  The  message  is 
not  removed  from  the  communication  space,  only  the  ownership  changed.  We 
can  allow  the  message  to  have  constituents  because  it  is  not  removed. 


destroy  [m  ,t  \\-  C  >  C 
preconditions 
m 

t^EM 

r  e/_ 
t^^R 
(r.ti)ei 

(r  ,m)ew 
then 

d'  -  u  -  \  {r  ,m)\ 


The  assert  operation  can  change  the  state  of  the  communication  space 
when  applied  to  constituents,  i.e.  a  message  is  made  the  constituent  of  another. 
The  role  issuing  the  operation  must  own  both  messages  and  have  modify  access 
to  the  aggregate  message. 
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assert  [mo.tQ.rrii.t  i,r  .t2\'  C  ^  C 
let 

K  =  {m  \  {m,mi)enl 
precomlilions 
rriQEj 
toCM'a 
(mo,^o)ert 
rrix^J 

r£l 

(r,77i.o)€w 

(r  ,mi)ec3 
(^2. ^0)^77 

/r  =  0 

then 

7f'  =  W  ij  K^0.”^l)i 

The  remove  operation  can  change  the  state  of  the  communication  space 
when  applied  to  constituents,  i.e,  a  message  is  removed  from  another  message’s 
set  of  constituents.  The  role  issuing  the  operation  must  own  both  messages  and 
have  niDdify  access  to  the  aggregate  message. 


remove  ii'^.^2];  C  -»  C 

precomlitions 

mpE/ 

fpEjt/a 

(mo.Zo)Et 

my£l 

t^£M 

i)el 

T£l_ 

t  2^-R 
{r,tz)^l_ 

{tQ,t  i)£n 
(mo,mi)€ff 
(r  ,mo)Ew 

then 
ff'  =  7T  - 

The  submit  operation  allows  a  role  to  share  ownership  with  one  of  its  mail 
addresses.  The  specified  address  must  play  the  role  and  the  message  cannot 
already  be  in  circulation.  The  role  must  have  send  access  to  the  message. 
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submit  [m .tQ,r  ,t  i,a  ,12]  C  ^  C' 
preconditions 

i 

toCM 
(m,^o)eT 
r^I  _ 
tyeR 

a^I 

^^G/l 

(a,^2)G^_ 

(r ,a)ep 
{r,m)€u  _ 

~(3  b){b  G/o  a(6  ,7n)€w 
then 

=  o  u 

The  deliver  operation  transfers  ownership  of  a  message  from  a  mail 
address  to  its  associated  role.  The  role  must  have  read  access  to  the  message. 

deliver  [m,tQ,r  ,t  i,a,t2]'.  C  C 
preconditions 
m 

r  g/_ 

{r,t_{)EL 
ae/_ 
tz^-A 
{n,t^  GI 

(r.a)Gp 

(a,77i)G&; 

then 

w’  =  (w  -  \{a.7n)])  u  l(r.m)j 

The  forward  operation  transfers  ownership  of  a  message  from  one  address 
to  another.  The  address  issuing  the  operation  must  be  connected  to  the  receiv¬ 
ing  address.  The  issuing  address  loses  ownership  of  the  message. 
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forward  [;m  i,az,tz\  ^  C" 

preconditions 
m  (lI_ 

a^c/ 

t^eA 

(ai.(i)ei 

0.2^1 

t2CA 

{a2.tz)^_ 

(ai.ag)^^ 

(ai.m)€cj 

then 

o’  =  (w  -  [{a^.m)])  u  [{a2,m)l 

The  share  operation  gives  ownership  of  a  message  to  another  address.  The 
issuing  address  still  retains  ownership  of  the  message.  The  issuing  address 
must  be  connected  to  the  receiving  address. 


share  C  ->  C 

preconditions 
m 

(m,io)6T 

ttiE/ 

tiEA 

agC/ 

t2^A 

(a2,^2)£l 

(ai.ag)^^ 

(ai,m)eo 

then 

o'  =  o  u  \{a2.Tn)l 

The  drop  operation  removes  a  message  from  circulation  along  a  particular 


path 
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drop  [m  ,tQ,a  ,t  i]  C  -»  C 
preconditions 
m^J 
todM 

ac/_ 

ti^A 

{a,m)€.o 
then 
D'  =  w  - 
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Chapter  4 

Addressing  Schemes 

The  addressing  scheme  model  was  first  introduced  by  Tsichritzis  [TsicB3], 
We  have  incorporated  the  model  into  our  larger  MMS  model  to  represent  the  cir¬ 
culation  of  messages  within  a  MMS.  The  work  in  this  chapter  shows  how  address¬ 
ing  schemes  can  be  used  to  formally  describe  message  routing  and  important 
properties  of  message  systems. 

The  addressing  scheme  model  is  an  abstraction  tool  for  dealing  with  the 
naming  and  addressing  problem  in  message  systems.  This  problem  has  received 
a  great  deal  of  attention  and  several  particular  solutions  have  been  presented 
[SchiBS.GaKuBl].  But  these  solutions  have  failed  to  deal  with  the  problem 
abstractly  and  independent  of  any  considerations  of  the  physical  routing  of  the 
messages. 

Problems  arise  in  message  systems  when  we  try  to  reconcile  the  addresses 
used  by  the  system  (usually  digital  addresses)  with  what  is  convenient  for  the 
user  (names,  postal  addresses,  affiliations,  nicknames,  etc.).  There  are  also 
difficulties  dealing  with  users  that  move  from  one  physical  address  to  another 
within  the  message  system.  An  addressing  scheme  describes  a  network  of  logi¬ 
cal  addresses  and  the  mapping  to  the  physical  addresses  is  transparent  and  can 
be  easily  altered  without  changing  the  logic  of  the  routing. 

The  addressing  scheme  model  also  allows  us  to  represent  the  logic  of  the 
routing  for  the  messages.  This  routing  can  be  based  on  the  contents  of  the  mes¬ 
sage  and  the  state  of  the  addressing  scheme.  The  model  represents  the 
knowledge  as  a  procedure  and  obtains  a  large  amount  of  flexibility. 
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The  addressing  scheme  is  a  pivotal  part  of  our  MMS  model.  It  performs  the 
circulation  of  the  messages,  in  essence  it  defines  how  communication  is  to  be 
carried  out.  The  network  of  addresses  in  the  scheme  can  be  thought  to  support 
the  communication  base  which  provides  the  interface  to  the  user. 

An  addressing  scheme,  as  stated  previously,  is  a  way  of  specifying  and 
interpreting  information  on  messages  that  eventually  brings  them  to  the  atten¬ 
tion  of  the  proper  recipients.  The  main  objects  of  an  addressing  scheme  are 
messages,  addresses  and  the  network  that  defines  the  addresses’  connectivity. 

There  are  the  two  kinds  of  addresses,  mail  and  routing,  in  an  addressing 
scheme  and  the  network  is  defined  by  the  set  of  connections  for  each  address. 
A  message  routing  through  the  network  is  accomplished  by  a  set  of  routing  pro¬ 
cedure  executions.  A  routing  procedure  is  executed  at  each  address  visited  by  a 
message  while  in  circulation.  We  can  categorize  addressing  schemes  according 
to  where  the  routing  procedures  reside  [Tsic63].  In  an  address  logic  scheme 
messages  are  completely  passive.  The  routing  procedures  are  associated  with 
the  addresses.  The  logic  present  in  each  address  decides  whether  it  should 
keep  a  received  message  and  to  where  it  should  forward  the  message.  In  a  mes¬ 
sage  logic  scheme  the  routing  procedures  are  associated  with  the  messages. 
ythen  a  message  arrives,  it  obtains  the  address  identification  and  has  access  to 
the  information  stored  in  the  address.  The  message  itself  decides  whether  it 
should  leave  a  eopy,  to  what  addresses  it  should  go  next  and  whether  it  should 
retain  some  of  the  information  available  to  it. 

Two  other  aspects  of  addressing  schemes  that  have  to  do  with  the  inter¬ 
dependence  of  messages  are  memory  and  coordination.  An  addressing  scheme 
will  be  called  memoryless  if  an  address  does  not  remember  anything  about  the 
messages  which  have  previously  passed  by,  including  those  messages  accepted. 
An  addressing  scheme  will  be  called  coordination  free  if  it  processes  each  mes- 
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sage  separately  without  reference  to  other  messages  which  may  be  waiting  for 
processing  at  the  same  address, 

We  define  an  addressing  scheme  to  be  a  subset  of  the  communication 
space.  The  main  objects  are  messages  and  addresses  which  are  defined 
according  to  message  types  {M)  and  address  types  (>1)  respectively.  The  address 
network  is  defined  by  the  connectivity  relationship  ic.  We  assume  4,  M,  A  and  ic 
to  be  fixed  for  a  particular  addressing  scheme.  The  messages  in  the  scheme,  i.e. 
in  circulation  at  any  one  time,  vary  and  are  always  a  subset  of  J^.  The  following 
discussions  all  concern  address  logic  schemes.  So  for  each  an  addressing 

scheme  contains  a  routing  procedure  Pi  that  is  executed  local  to  that  address. 

The  addressing  scheme  model  provides  a  framework  from  which  we  can 
describe  and  analyze  important  properties  of  message  routing.  The  three  pro¬ 
perties  we  investigate  in  the  remaining  sections  of  this  chapter  are  complete¬ 
ness,  serializability  and  time  independence.  The  presence  of  completeness 
ensures  that  messages  are  always  delivered.  Serializability  provides  a  con¬ 
current  notion  of  correctness.  We  are  able  to  comprehend  the  effect  one  mes¬ 
sage  has  on  the  routing  of  another  if  the  messages  are  routed  serially,  i.e.  the 
messages  are  put  into  circulation  one  at  a  time.  Messages  arrive  at  all 
addresses  in  the  same  order  and  change  the  addresses'  local  memories  in  the 
same  order.  But  in  actual  routings  many  messages  are  in  circulation  at  the 
same  time  and  are  moved  about  concurrently.  A  serializable  routing  for  a  set  of 
messages  has  the  same  effect  on  local  memories,  and  delivers  messages  to  the 
same  addresses,  as  a  serial  routing  for  the  same  set  of  messages.  Time 
independence  means  that  the  destinations  remain  the  same  no  matter  the 
length  of  time  a  message  must  spend  in  circulation.  All  three  properties  are 
important  to  providing  user  confidence  in  a  message  system.  We  first  introduce 
the  concept  of  a  routing  log  to  formally  describe  message  routings 
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4.1.  Ttouting  logs 

A  routing  for  a  message,  or  a  set  of  messages,  is  the  circulation  of  the 
message(s)  through  the  addre:  s  network  of  an  addressing  scheme.  We  use  the 

notation  Rlrrii . to  r  epresent  a  routing  R  over  a  set  of  messages 

fmi,  .  .  .  .rrinl.  At  each  address  visited  by  a  message  the  procedure  associated 
with  the  address  is  executed  o  determine  the  next  step  in  the  routing.  This 
next  step  can  be  a  transfer  of  1  he  message  to  one  or  more  connected  addresses 
or  the  transfer  of  the  message  out  of  circulation,  i.c.  the  message  reaches  one 
of  its  destinations.  A  message  may  concurrently  travel  several  paths  in  the  net¬ 
work.  This  corresponds  to  a  nressage  going  to  a  set  of  destinations.  A  routing 
ends  when  all  the  messages  let  ve  the  scheme  from  all  paths  in  the  routing.  The 
circulation  of  a  particular  m  issage  may  be  influenced  by  other  messages. 
Addresses  with  memory  use  in  ormation  they  have  stored  about  previous  mes¬ 
sages  to  make  their  routing  v:ecisions.  Addresses  with  coordination  refer  to 
other  local  messages  to  make  t  leir  routing  decisions. 

We  use  a  routing  log  (or  Icj)  to  model  an  allowable  routing  of  a  set  of  mes¬ 
sages  (adapted  from  transaction  logs  in  serializability  theory  [BeGo82]).  By  an 
allowable  routing,  we  mean  one  that  produces  a  sequence  of  consistent  states  of 
the  communication  space,  i.e.  each  state  satisfies  the  axioms  of  Section  3.8.1. 

Formally,  a  log  over  a  ro  iting  R\mi,  .  .  .  ,m^]  is  a  partially  ordered  set 
!,  =  (S,<)  where  E  is  the  set  c"  routing  procedures  executed  at  the  addresses 
visited  by  all  the  ttl^’s  (l<i-sn  )  and  <  is  the  partial  ordering  on  these  execu¬ 
tions.  The  partial  order  <  indicates  the  order  of  the  addresses  visited,  or 
equivalently,  the  paths  follower  ,  by  each  and  other  constraints  on  the  order 
of  execution  (which  we  discuss  below).  We  note  that  the  partial  order  <  is  tran¬ 
sitive. 

We  represent  each  elemert  of  E  with  the  notation  /^y[  Vj^],  i.e.  message 
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visits  address  aj  and  procedure  Pj  is  executed.  During  the  execution  the  set  of 
variables  in  local  memory  (1^)  is  accessed,  We  assume  that  and  that 

each  variable  x£Vji  is  accessed  and  has  its  value  altered.  We  require  that  every 
variable  in  Vji  have  its  value  altered  because  otherwise  there  is  no  way  to  tell 
that  message  has  been  processea  by  address  Oj  and  that  the  variable  was 
used  to  determine  the  routing  of  We  let  Py  []  represent  a  procedure  execu¬ 
tion  where  no  local  memory  is  accessed.  We  assume  the  execution  of  a  pro¬ 
cedure  at  an  address  is  atomic.  An  execution  of  the  procedure  for  one  message 
can  not  be  interrupted  in  order  to  execute  for  another  message. 

A  log  can  be  represented  by  a  graph  whose  edges  indicate  the  partial  order 
<•  The  graph  for  the  routing  of  a  single  message  is  just  a  tree.  Figure  4.1  shows 
the  graph  of  a  log  over  a  routing  where  m,  originates  at  address  O]  and 

then  follows  two  paths  -  a,  -  ag  -  and  o-i  -  a^.  These  paths  are  indicated  by 
the  partial  orderings  Pll[]  <  P12[]  <  P14[]  and  Pll[]  <  P?5[]. 

If  an  address  is  visited  by  a  message  rrq  more  than  once  in  a  routing  then 
its  associated  procedure  appears  more  than  once  in  E,  A  loop  in  a  path  followed 
by  results  in  a  partial  order 

•  •  Pi)  <P*<  ■  •  <  Pi)  <PiJc  <  ■  ■ 

and  the  corresponding  path  in  the  graph  is  of  infinite  length.  A  procedure  may 
also  appear  more  than  once  if  an  address  is  on  more  than  one  of  the  paths  fol¬ 
lowed  by  a  message.  These  executions  may  not  be  related  by  the  partial  order  <. 

There  are  two  further  constraints  on  the  form  of  logs.  We  say  two  pro¬ 
cedure  executions  conflict  if  they  are  at  the  same  address  and  their  memory 
references  overlap  That  is,  for  messages  rrij  and  mg,  the  executions 
and  P2i'0i2\  conflict  when  assume  that  all  variables  in  local 

memory  that  are  referenced  during  an  execution  affect  the  routing  of  the  mes¬ 
sage  and  have  their  values  changed  by  the  execution.  So  the  prior  execution  of 
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R1 


P12[  ] 


P13[y31] 


Fiaure  4.1:  Routing  Log 


>  P14[] 
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Fi  for  m-i  has  an  effect  on  the  routing  of  mg.  We  require  that  all  conflicting 
pairs  of  executions  in  a  log  be  ordered.  Otherwise,  there  is  no  way  to  tell  if  the 
subsequent  steps  in  a  routing  are  valid,  i.e.  they  follow  from  the  processing 
done  at  the  address.  An  example  of  a  log  L  over  ....  with  conflicting 

executions  is  shown  in  Figure  4.2. 

The  second  constraint  deals  with  the  coordination  of  messages.  Coordina¬ 
tion  is  represented  by  a  set  of  procedure  executions  (not  necessarily  consecu¬ 
tive)  at  a  particular  address.  The  result  of  all  but  the  last  execution  is  to  place 
the  current  message  into  local  memory  and  leave  the  state  of  the  communica¬ 
tion  space  unchanged.  The  result  of  the  last  execution  is  to  route  the  current 
message  and  all  those  messages  stored  by  the  previous  executions.  The  order  of 
arrival  of  the  messages  is  not  important.  We  assume  the  same  routing  is  per¬ 
formed  when  all  the  messages  are  present  no  matter  what  the  order.  If  order 
does  matter,  then  we  can  represent  this  by  accesses  to  variables  in  local 
memory,  eg.  Pij[Vji\-  Otherwise  we  will  just  use  the  notation  Fij[]  when  refer¬ 
ring  to  coordinated  executions. 

Formally,  we  say  a  set  of  procedure  executions  at  the  same  address 
(Fii[],  coordinate  if  all  procedure  executions  must  be  performed 

before  the  routing  of  all  the  associated  messages  can  continue.  That  is,  if 
for  some  l<;<n  and  then  Pii[]  <Pj.  []  for  all  I  such  that 
The  presence  of  coordination  in  a  log  can  be  indicated  as  in  Figure  4.3. 
The  messages  ttiq  and  m.^  are  coordinated  at  address  a2  and  both  executions 
P02!.]  Fi2[]  must  occur  before  both  messages  can  be  transferred  to  a^. 

We  assume  the  existence  of  two  special  addresses  -  and  a.j)  -  to  act  as  the 
source  and  sink,  respectively,  of  all  messages  in  the  scheme.  These  are  for 
notational  convenience.  The  address  a^  is  connected  to  each  mail  address.  The 
execution  of  a  submit  operation  moves  a  message  from  05  to  the  appropriate 
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L  = 


P01[  ] 


P02[y20] 


F I  sure  4.2:  Log  L  over  R[tn0/ml /m2^m3/m4] 
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P01[] 


P13[] 


P04[  3 


P14[  ] 


Figure  4.3:  Coordinated  Procedure  Executions 
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mail  address.  Each  mail  address  is  connected  to  aj)  and  the  execution  of  a 
deliver  operation  moves  a  message  from  a  mail  address  to  a/). 

ObsenjationA  valid  routing  R[mi . m^]  is  a  function  from  C  -»  C  where  C is 

the  set  of  states  for  the  communication  space. 

Argurnentyfe  can  consider  each  routing  procedure  execution  Pij  to  be  a  func¬ 
tion  Pij.C-^C.  The  effect  of  Pij  on  the  state  of  the  communication  space  is 
the  combined  effect  of  all  circulation  operation  executions  within  Pij.  We 
knov/-  the  effect  of  each  individual  circulation  operation  from  Chapter  3,  We 
can  determine  the  combined  effect  using  standard  rules  of  inference  for 
the  programming  language  constructs  of  the  routing  language.  For  exam¬ 
ple.  see  Hoare  [Hoar69]  or  Hoare  and  Lauer  [ HoLa74]. 

Now  suppose  L  is  a  log  over  R[mi . We  can  perform  a  topological 

sort  iAhHL'74]  on  the  graph  of  L  to  obtain  a  linear  representation 

^  ~~  {PbuiPbu  +  l . ^bv . Pcx i-li  ■  ■  '  ^cy') 

where  l<c,  ...  c<n  and  Oy.aj^  +  i,  .  .  .  .Oy  are  all  addresses. 

If  we  perform  the  procedui’e  executions  in  the  order  of  L'  we  get  a 
sequence  of  states  [Cq.C^,  ...  Cj)  such  that  Pbu.Co^Ci,  Pint  +  i-Ci-^Cs, 

We  know  that  the  topological  sort  will  preserve  <  from  L  and  that 

/?[mj . 771^]  is  a  valid  routing.  So  executing  any  pair  Pij  and  Pfy^  such 

that  P-ij  <  P^  must  yield  a  valid  state  (assuming  the  initial  state  is  valid). 

Tnat  IS,  the  axioms  of  the  communication  space  are  preserved.  Also,  exe¬ 

cuting  any  pair  Py  and  Pfy^  that  are  not  related  by  <  must  yield  a  valid 
state  since  the  executions  have  no  effect  on  each  other  and  individually 
they  yield  valid  states.  Therefore  Cf  must  be  a  valid  state  of  the  communi¬ 
cation  space,  i.e.  Cf£C 


-69- 


Therefore,  R\mi,  .  ,  , 

4.2.  Completeness  in  Addressing;  Sehemes 

An  addressing  scheme  will  be  called  complete  if  it  eventually  delivers  all 
possible  generated  messages,  i.e,  any  sequence  of  messages  originating  in  the 
scheme  eventually  gets  delivered  and  the  scheme  reaches  the  empty  state 
[TsicB3].  This  is  an  important  property  for  addressing  schemes  Messages  will 
not  circulate  forever  or  get  stuck  at  some  address  in  a  complete  scheme.  Users 
are  assured  of  the  reliability  of  the  scheme  and  should  be  willing  to  use  a  mes¬ 
sage  system  that  is  guaranteed  not  to  "lose"  their  messages. 

Formally,  for  any  set  of  messages  .  .  .  ,  rrq J  submitted  to  addresses 
a^,  .  .  .  .a^  (not  necessarily  unique),  addressing  scheme  A  is  complete  if  all 
routings  i?for  the  set  of  messages  result  in  all  messages  eventually  leaving  cir¬ 
culation. 

Definition. kn  addressing  scheme  A  is  complete  if  for  any  state  C  of  the  commun¬ 
ication  space 

(3mi,  .  .  .  ,m^){3  a^,  .  .  .  ,a^){lmi,  .  . 

. 

then,  for  all  routings  Rior  the  messages,  R[mi,  .  .  ,mn\  :  C  ^  C  where 

~(3  a)(a,77q)ecj'  l<i<n. 

We  assume  the  rrq's  are  unique  but  the  cl^’s  are  not  necessarily  unique  and 
=  as  means  that  m^  is  not  yet  in  circulation. 

We  examine  three  main  categories  of  addressing  schemes:  (.1)  memoryless 
and  coordination-free  schemes;  (2)  schemes  with  memory  but  coordination- 
free,  and  (3)  schemes  with  memory  and  coordination.  As  the  properties  of 
memory  and  coordination  are  added  the  functionality  of  the  schemes  are 
increased,  but  so  is  the  complexity  of  the  routing  within  the  schemes. 
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4.2.1.  Memoryless  and  Coordination-free  Schenaes 

A  memoryless  and  coordination-free  addressing  scheme  routes  each  mes¬ 
sage  independently  of  any  other  messages  in  circulation.  The  routing  is  based 
only  on  the  information  present  in  the  message  itself.  When  a  message  arrives 
at  an  address  the  associated  routing  procedure  is  executed  (perhaps  some  time 
later  if  there  is  a  queue  of  new  messages)  and  the  state  of  the  communication 
space,  with  respect  to  that  message,  is  changed. 

A  memoryless  and  coordination-free  scheme  is  complete  if  and  only  if  (l) 
every  Pj  executed  for  a  message  eventually  halts,  and  (2)  there  are  no  loops  in 
any  of  the  paths  followed  by  a  message.  If  a  scheme  is  complete  then  no  mes¬ 
sage  gets  "stuck"  in  circulation,  i.e.  every  message  eventually  leaves  the 
scheme.  Thus  every  procedure  execution  must  halt  and  every  path  be  of  finite 
length.  Since  there  are  a  finite  number  of  addresses  in  any  scheme,  an  infinite 
path  must  contain  a  loop.  Therefore  loops  are  not  possible  in  a  complete 
scheme.  Conversely,  if  all  procedure  executions  halt  and  there  are  no  loops  in 
any  of  the  paths  followed  by  a  message,  then  no  message  can  get  stuck  in  the 
scheme.  Therefore  the  scheme  is  complete. 

The  routing  procedures  Pj.  .  .  .  ,P„  compute  functions  of  C^C,  where  C  is 
the  set  of  states  for  the  communication  space.  The  P^'s  will  halt  if  they  com¬ 
pute  total  functions  We  restrict  the  P^'s  to  represent  the  primitive  recursive 
functions  (in  fact  most  computer  programs  compute  primitive  recursive  func¬ 
tions  so  the  restriction  is  not  a  critical  one). 

We  define  a  routing  language  KL  (see  Appendix  1)  to  speeify  the  P^'s  such 
that  the  mapping  to  primitive  recursive  functions  is  assured.  The  important 
feature  of  RL  is  the  absence  of  GOTO’s.  Programming  languages  without  GOTO's 
and  with  bounded  loops  (i.e.  loops  guaranteed  to  execute  a  finite  number  of 
times)  and  simple  assignments  have  been  previously  shown  to  map  to  the 
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primitive  recursive  functions  [BrLa74].  We  specify  RL  to  contain  bounded  loops, 
IF-THEN-ELSE  statements  (which  can  be  implemented  as  bounded  loops),  CASE 
statements  (which  can  be  implemented  as  bounded  loops),  simple  assignments 
to  variables  and  calls  to  the  circulation  operations. 

Observation.Every  execution  of  a  routing  procedure  written  in  RL  is  guaranteed 
to  halt. 

Argument-.We  first  assume  that  when  an  execution  of  some  Pj  halts  it  changes 
the  state  of  the  communication  space.  If  the  execution  of  some  P^  falls 
through  the  last  statement  the  message  is  automatically  dropped  from  cir¬ 
culation  at  that  point. 

Consider  the  routing  procedures  Pj,  .  .  .  ,  P„  .  We  know  that  they  are  written 
in  RL  and  must  obviously  be  of  finite  length.  So  if  a  procedure  does  not  halt 
it  is  because  of  the  properties  of  the  statements  and  not  its  length.  Previ¬ 
ous  work  !BrLa74]  has  shown  that  programs  written  in  RL  -  ^circulation 
operations!  compute  primitive  recursive  functions  and  are  guaranteed  to 
halt.  Thus  if  we  show  there  is  a  mapping  from  the  circulation  operations  to 
primitive  recursive  functions  then  all  RL  programs  (routing  procedures) 
must  halt. 

We  define  each  of  the  circulation  operations  as  functions  of  C  *C.  The  nota¬ 
tion  f  orward^y  is  read  "forward  m  at  (ij  to  aj".  We  let  C  and  C  be  states 
and  w  and  u'  be  the  sets  corresponding  to  the  owns  relationship  for  those 
states.  The  circulation  operations  are 

(1)  f  oTwardjr^j  C  where  w'  =  ^[j\m ,aj  l—\Tn 

(2)  share fnij  .C  ->C'  where  Z>'  = 

(3)  submit^  C  -*0'  where  u  = 

(4)  deliver^^:C  -»  C  where  cj'  = 

(6)  E  -»  C  where  w'  = 
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We  encode  the  messages  with  standard  methods  to  produce  a  natural 
number.  Say  v{m)  is  the  encoding  for  m.  Similarly  we  encode  the  address 
names  -  say  v  (oj)  is  the  encoding  for  -  such  that  v{ai)i>tv  {aj)  . 

We  now  map  the  routing  functions  to  functions  on  N  (natural  numbers). 
The  new  functions  encode  all  the  relevant  information  for  the  routing  of  a 
particular  message  m  by  incorporating  the  address  numbers  with  the  mes¬ 
sage  number.  We  let  t  represent  the  number  built  so  far  by  the  routing. 
Originally  t=v{m).  The  respective  encoding  functions  are 

(2)  sfiij{t)=t  +v  {aj){l0^y 

(3)  siLi{t)=t  4-T;(ai)(lCP)^ 

(4)  dei{t)=t--v{ai){l(fy 

(5)  cfri(0=^-'i^(ai)(lO*)" 

where  10*>i'(m)  for  ail  possible  generated  messages  m. 

We  know  that  functions  of  the  form  of  /y,  are  primitive  recursive.  So 
all  the  procedures  written  in  RL  can  be  mapped  to  primitive  recursive 
functions.  Therefore  any  execution  of  the  P^'s  must  halt  for  every  message 
m. 

The  other  consideration  for  a  message  routing  is  the  path  followed  by  that 
message  ^  message  will  get  "stuck"  in  circulation  if  the  path  is  of  infinite 
length.  We  know  there  are  a  finite  number  of  addresses  in  a  scheme  so  a  path 
will  be  infinite,  and  the  routing  of  that  message  never  halt,  only  if  there  is  a 
cycle  in  the  path. 

One  way  to  ensure  that  there  are  no  loops  in  any  paths  followed  by  a  mes¬ 
sage  IS  to  construct  the  address  network  such  that  there  are  no  cycles.  But  we 
are  then  limited  to  schemes  with  tree  networks  as  in  Figure  4.4  Any  address 
can  transfer  messages  only  to  its  children  and  receive  messages  only  from  its 
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Figure  4.4:  Tree  Network 
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anceslors. 

It  is  also  possible  to  try  and  detect  in  advance  any  messages  that  will  get 
caught  in  a  cycle  and  eliminate  them  from  the  scheme.  We  therefore  transform 
any  memoryless  and  coordination-free  scheme  into  an  equivalent  complete 
scheme. 

Obse7^;a^^on: Suppose  A  is  a  memoryless  and  coordination-free  addressing 
scheme  such  that  all  its  routing  procedures  are  written  in  RL.  Then  it  is 
possible  to  construct  an  equivalent  scheme  A'  that  is  complete  for  the  set 
of  messages  delivered  by  A. 

Argument. yfe  say  two  addressing  schemes  are  equivalent  if  they  handle  the 
same  set  of  messages,  have  the  same  set  of  mail  addresses  and  deliver 
messages  to  the  corresponding  mail  addresses  jTsic63]. 

We  know  that  the  path  a  message  follows  is  determined  a  step  at  a  time.  At 
each  address  a  decision  is  made  based  on  the  type  and  contents  of  the  mes¬ 
sage.  We  will  use  the  notation  py  to  represent  a  predicate  that  if  true  will 
move  a  message  from  ctj  to  Uj.  It  is  possible  for  a  message  to  satisfy  more 
than  one  predicate  at  an  address.  The  path  will  branch  into  several  at  that 
point. 

We  can  describe  an  equivalence  class  of  messages  in  terms  of  these  predi¬ 
cates.  If  a  message  follows  a  path  ag  ,  ,  .  ,  (in.o-n  then  it  must 

satisfy  the  predicate 

Pl2  nD  -  P\2'^P23‘^  '^PnD 

In  fact,  a  set  of  messages  will  satisfy  this  predicate  and  all  be  routed  down 
the  same  path. 

We  obtain  all  the  path  defining  predicates  by  starting  at  as  and  performing 
a  depth-first  search  of  the  address  connecting  graph  [AhHU74j.  As  an  arc 
of  the  graph  is  taken  the  predicate  for  that  arc  is  "anded"  to  the  path 
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predicate. 

We  need  only  deal  with  paths  of  finite  length  so  the  process  must  halt.  A 
path  will  either  end  with  the  message  being  delivered  (i.e.  at  ajj)  or  a  cycle 
will  appear.  We  know  this  is  true  because  there  are  a  finite  number  of 
addresses  in  any  scheme.  We  assume  that  the  contents  of  a  message  can¬ 
not  be  changed.  Changing  the  contents  of  a  message  means  that  a  message 
may  change  equivalence  classes.  This  makes  path  determination  a  very 
hard  problem.  So  the  second  appearance  of  any  address  in  a  path  means 
that  the  message  has  entered  a  cycle.  Suppose  we  are  following  a  path  and 
encounter  a  cycle.  Say  so  far  we  have  built  up  the  predicate  Piza  q- 
create  a  new  procedure  P^'  by  altering  the  procedure  Fj  at  the  starting 
address  a,  to  check  for  and  drop  any  messages  that  match  p  123  q. 

When  the  depth-first  search  algorithm  backs  up  a  path  we  remove  the 
appropriate  arc  predicate  from  the  conjunction  that  forms  the  path  predi¬ 
cate,  We  must  assume  that  no  two  paths  with  the  same  origin  can  have  the 
same  path  predicate.  Otherwise,  if  one  of  these  paths  has  a  cycle  we 
remove  the  possibility  of  messages  being  delivered  via  the  other  path. 

The  scheme  A'  delivers  all  the  messages  that  were  delivered  by  A  and  drops 
any  messages  that  got  stuck  in  A.  Therefore  A'  is  complete  for  those  mes¬ 
sages  delivered  by  A.  A'  handles  the  same  messages  as  A,  has  the  same  mail 
addresses  as  A  and  routes  those  messages  delivered  by  A  to  the  same  desti¬ 
nations.  Therefore  A'  is  equivalent  to  A. 

As  an  example  of  this  procedure  consider  the  addressing  scheme  A  com¬ 
posed  of  addresses  ,  .  ,  ,ae{  with  the  connectivity  network  given  in  Figure 
4.5.  If  we  start  at  address  Uj  we  obtciin  the  path  predicates 

P\z‘^PzD> 

P\z'^Pzz'^PzD< 


-76- 


Figure  4.5:  Network  for  Addressing  Scheme  A 


-  77- 


Pl2'^P23'^P31. 

P  1 2  23  ^P  36  '^P  6D . 

P  1 2 '^P  23 '^P  36  ^P  62 

'ITie  two  predicates  P1231  and  p  12302  represent  classes  of  messages  that  get  into 
loops  in  A.  In  constructing  the  new  scheme  A',  we  construct  the  new  procedure 
Pi'  that  checks  for  messages  that  match  either  p  1231  or  p  12302  and  drops  them. 
The  rest  of  Pi’  is  the  same  as  P^  We  do  the  same  for  each  mail  address  in  A, 

4.2.2.  Coordination-free  SchenKS  with  Memory 

We  next  consider  the  introduction  of  memory  At  some  of  the  addresses  in 
the  scheme  we  provide  local  memory  in  the  form  of  instance  variables  in  the 
associated  routing  procedure,  These  variables  can  store  patterns  from  mes¬ 
sages  or  be  used  as  counters.  The  patterns  are  used  to  represent  properties 
such  as  the  same  origin,  same  subject,  a  particular  attribute  value  or  a  particu¬ 
lar  string  of  text.  All  messages  containing  the  pattern  are  assumed  to  have  the 
associated  property.  If  memory  is  used  in  this  way  then  cycles  in  a  path  can  be 
detected.  But  this  restricted  use  of  memory  does  not  facilitate  coordination. 
Every  message  is  processed  based  only  on  information  in  its  contents  and  the 
information  the  address  has  retained  about  previous  messages. 

As  with  memoryless  schemes,  if  we  assume  the  routing  procedures  are 
written  in  RL,  messages  will  become  stuck  in  circulation  only  if  there  is  an 
infinite  loop  in  one  of  their  paths.  There  must  be  a  cycle  in  the  address  network 
for  a  loop  in  a  path  to  exist.  But  the  inclusion  of  memory  means  that  a  cycle 
may  only  be  traversed  a  finite  number  of  times.  An  address  with  memory  can 
keep  track  of  the  number  of  times  a  message  loops  in  a  path.  So  not  only  is  the 
presence  of  a  cycle  Important,  but  also  how  memory  is  used  by  addresses  in  the 
cycle. 

Memory  can  be  used  to  store  patterns  and  counters.  Thus  it  is  possible  for 


-  ?8- 


an  address  with  memory  to  store  the  -id  of  a  message  it  has  processed  and  then 
check  new  arrivals  to  make  sure  the  same  message  does  not  return.  If  a  mes¬ 
sage  does  return  it  can  be  dropped,  We  can  vary  this  use  of  memory.  For  exam¬ 
ple,  an  address  may  keep  a  count  and  allow  a  message  to  loop  a  finite  number  of 
times,  or  an  address  may  only  process  a  certain  number  of  messages  with  a 
particular  property  and  then  drop  any  more  that  arrive. 

Obse-ruaiion: Suppose  A  is  a  coordination-free  addressing  scheme  with  memory 

such  that  all  routing  procedures  are  written  in  RL.  Let  a, . be  the 

addresses  without  memory  and  0,^1  +  ! . be  the  addresses  with 

memory.  We  can  construct  an  addressing  scheme  A'  that  is  equivalent  to  A 
and  A'  is  complete  for  the  set  of  messages  that  get  delivered  in  A. 

Argument yie  proceed  as  in  the  memoryless  case.  We  perform  a  depth-first 
search  of  the  address  connecting  graph  starting  at  05  and  obtain  the  path 
predicates.  We  look  for  cycles  in  the  paths  and  must  handle  two  cases:  (1) 
all  the  addresses  in  the  cycle  are  memoryless,  and  (2)  one  or  more  of  the 
addresses  in  the  cycle  have  memory. 

First  consider  cycles  with  all  memoryless  addresses.  If  we  have  built  up  the 
predicate  Pi2  q  till  the  cycle  is  found  then  we  can  create  the  new  pro¬ 
cedure  Pi'  to  test  for  messages  that  match  the  predicate  and  drop  them. 
Another  solution  is  to  insert  a  new  routing  address  with  memory  (adding  a 
routing  address  still  leaves  an  equivalent  scheme  [Tsic83]). 

Suppose  the  cycle  in  the  path  is  (a^t,  +  i  ,  Uq).  We  insert  routing 
address  a'  into  the  network  such  that  is  connected  to  a'  and  ex'  is  con¬ 
nected  to  a* 4.1,  We  alter  such  that  if  it  moved  a  message  to  +  then 
Pif'  will  move  the  message  to  a'.  The  procedure  at  a'  will  check  to  see  if  the 
message  has  passed  through  previously,  If  it  has  then  the  message  is 
dropped.  If  this  is  the  first  visit  by  the  message  the  procedure  records  the 
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id  and  forwards  the  message  to  a^  +  i-  Thus  any  message  In  a  loop  in  A  will  be 
dropped  in  A', 

Now  consider  cycles  with  one  or  more  addresses  with  memory.  Suppose  we 
have  a  cycle  with  addresses  at,  ttin,  ■  •  ■  .  (Xj.  We  have  to  determine 
whether  the  loop  in  the  path  is  finite  or  infinite.  We  examine  each  Pk 
i<k<j  and  see  how  memory  is  used.  We  want  a  with  the  following 
characteristics.  The  predicate  />**  +  !  involves  one  or  more  variables  in 
memory  that  store  information  about  previously  processed  messages, 
including  the  number  of  times  each  has  visited  and  some  upper  bound 
on  the  number  of  visits.  P^  compares  the  number  of  visits  by  the  current 
message  with  the  upper  bound  and  takes  the  message  out  of  the  cycle  if 
the  bound  is  exceeded.  With  such  a  P^  the  loop  will  be  finite  and  no  change 
is  required,  But  if  this  is  not  the  case  then  we  create  a  new  procedure  P^' 
that  uses  memory  as  described,  checks  it  in  the  predicate  Pkk+i,  and  drops 
any  messages  that  have  previously  been  at  a*;. 

The  new  scheme  A'  handles  the  same  messages,  has  the  same  mail 
addresses  and  any  messages  that  reached  a  destination  in  A,  reach  the 
SoiTie  destinations  in  A'.  Those  messages  that  got  stuck  in  A  are  dropped  in 
A.'.  Therefore  A'  is  equivalent  to  A  and  it  is  complete  for  those  messages 
delivered  by  A. 

We  can  see  that  a  scheme  will  be  complete  if  the  connectivity  is  such  that 
every  cycle  in  the  address  network  contains  at  least  one  address  with  memory 
and  that  the  address  uses  the  memory  appropriately. 

The  amount  of  memory  required  at  an  Oi  to  guarantee  detection  of  a  loop 
must  be  enough  to  store  an  identifier  plus  a  counter  for  some  number  N  mes¬ 
sages,  vrlierc  N  is  an  upper  bound  on  the  number  of  messages  that  can  be  in  cir- 
cUiatiun  ai.  any  one  time.  Actually,  we  would  want  more  memory  so  we  could 
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also  keep  track  of  messages  with  particular  properties  (patterns).  We  do  not 
consider  the  problem  of  knowing  when  a  message  has  left  circulation  so  we  can 
free  up  memory.  We  at  least  assume  that  memory  can  be  freed  when  the  net¬ 
work  reaches  a  stable  state. 

Even  a  restricted  memory  facility  provides  schemes  with  a  great  deal  of 
increased  functionality.  An  example  of  a  complete  scheme  is  a  star  network 
(Figure  4.6)  with  a  routing  address  with  memory  at  the  center  and  mail 
addresses  surrounding  it.  Each  mail  address  requires  connections  in  both 
directions  with  the  central  routing  address  (which  are  represented  by  two- 
headed  arrows  in  Figure  4.6).  This  can  be  generalized  to  a  subnetwork  of  routing 
addresses  with  memory  in  the  center.  There  must  be  at  least  one  routing 
address  connected  to  each  mail  address  and  there  must  be  a  path  from  each 
routing  address  to  every  other  routing  address  to  ensure  each  mail  address  can 
be  reached. 

Another  example  of  a  complete  network  is  a  tree  with  the  root  node  having 
memory.  We  can  connect  every  leaf  node  to  the  root  and  have  a  much  more 
powerful  scheme,  in  terms  of  reachability,  than  the  memoryless  case. 

The  inclusion  of  memory  in  a  scheme  allows  for  much  more  complex  rout¬ 
ing.  A  network  can  contain  an  address  a  that  alternates  transferring  messages 
to  one  of  a  set  of  addresses  depending  on  the  value  of  some  variable  v.  For 
example,  a  routes  messages  to  Oj  if  mod(n)  =i.  It  is  also  possible  for  an 
address  to  only  accept  a  certain  number  of  messages  with  a  particular  property 
and  drop  the  rest.  This  is  a  method  of  handling  the  tiresome  problem  of  "junk 
mail" 

4.2.3.  Schemes  with  Memory  and  Coordination 

The  introduction  of  coordination  into  a  scheme  means  that  it  is  now  possi- 
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Fiaure  4.6:  Complete  Star  Network 
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ble  that  a  messa^'e  may  have  to  wait  at  an  address  until  one  or  more  other  mes¬ 
sages  arrive  before  it  can  be  routed.  We  represent  coordination  with  addresses 
that  can  store  messages  in  their  local  memory.  So  routing  procedures  must 
now  be  able  to  halt  with  the  result  of  (l)  not  changing  the  state  of  the  address¬ 
ing  scheme  but  just  storing  a  message  locally,  or  (8)  routing  more  than  one 
message  at  a  time,  i.e.  the  message  being  processed  plus  some  messages  stored 
in  local  memory  (this  also  means  a  change  to  local  memory). 

Coordination  presents  the  possibility  of  deadlock.  Two  or  more  addresses 
may  store  messages  that  each  other  needs  to  continue  the  routing  of  those 
messages.  Storing  a  message  is  analogous  to  locking  an  item  in  a  database.  If  an 
address  stores  a  message  then  all  other  addresses  on  possible  paths  from  that 
address  are  not  able  to  receive  the  message.  This  "locking"  applies  only  to 
addresses  on  paths  from  that  address,  other  independent  paths  in  the  message 
routing  are  not  affected. 

The  existence  of  deadlock  cannot  be  detected  just  with  an  initial  inspection 
of  the  address  network.  It  also  depends  upon  the  messages  in  circulation  and 
the  routings  of  those  messages. 

For  a  particular  set  of  messages  in  circulation  and  for  some  coordinating 
address  ai,  we  let  be  the  set  of  messages  held  by  and  let  Ji  be  the  set  of 
messages  coordinates.  The  messages  in  Hi  are  held  until  receives  all  the 
messages  in  and  then  the  messages  are  all  routed  at  once  Note  that  /j  may 
change  for  different  sets  of  messages  in  circulation  and  those  addresses  that 
perform  coordination  may  change.  We  define  the  partial  order  <i  to  be  a  res¬ 
triction  of  <  to  the  paths  of  message  rrij. 

Definition: A  routing  ,  .  .m^]  is  deadlocked  on  Imj,  ,  .  ,mj^\ 

!L  . rrinj.  if  there  exists  coordinating  addresses  Oj  ,  .  .  ,  such 


that 
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(1)  Jt  □  l<i<k 

(2)  Hi  ^  \mi\.  l^i<k 

(3)  <i  aj ,  \j  ^i,\<i,j<k  . 

Deadlock  occurs  in  a  routing  if  a  set  of  messages  all  follow  a  path  that  con¬ 
tains  two  or  more  coordinating  addresses  but  the  messages  do  not  visit  these 
addresses  all  in  the  same  order.  This  means  there  must  be  a  cycle  in  the 
address  network  that  contains  the  coordinating  addresses  in  order  for  deadlock 
to  be  a  possibility. 

CfeserT^odion: Suppose  A  is  an  addressing  scheme  with  memory  and  coordination 
and  that  all  routing  procedures  are  written  in  RL,  Let  a^,  .  .  .  be  the 
addresses  without  memory  and  let  +  .  .  .  ,  be  the  addresses  with 

memory  and  coordination  We  can  construct  an  addressing  scheme  A'  that 
IS  equivalent  to  A  and  complete  for  the  set  of  messages  delivered  by  A. 

Argument  'We  proceed  as  in  the  previous  two  arguments.  We  perform  a  depth- 
first  search  of  the  address  connecting  graph  starting  at  as  and  obtain  the 
path  predicates. 

We  look  for  cycles  in  the  paths.  From  the  previous  two  arguments  we  know 
how  to  modify  A  to  handle  cycles  with  only  memoryless  addresses  or  that 
contain  addresses  with  memory.  So  we  must  only  consider  cycles  with  two 
or  more  coordinating  addresses.  By  eliminating  those  messages  that 
deadlock  we  ensure  the  completeness  of  A. 

We  cannot  tell  if  a  particular  message  will  deadlock  at  the  time  of  its  sub¬ 
mission.  Coordination  involves  several  messages  and  the  occurrence  of 
deadlock  depends  upon  their  routings.  We  remove  deadlock  from  A  by 
installing  a  mechanism  that  can  detect  deadlock  and  eliminate  the  mes¬ 
sages  from  circulation. 
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Suppose  there  is  a  cycle  that  contains  coordinating  addresses  a^,  ■  ■  ■  ,a.(i 
which  all  coordinate  the  messages  mg.  .  .  .  That  is. 

Ji  =  {rric ,  .  .  . 

We  create  a  new  routing  address  a<'  with  memory  and  coordination.  It  is 
inserted  into  the  network  such  that  there  are  connections  from  each  cXi  to 
ttt'  and  from  to  each  ai  where  c<i<d. 

We  alter  the  for  each  so  that  the  new  procedure  P^',  whenever  it 
receives  one  of  will  record  the  fact  in  memory  and  then  for¬ 

ward  the  message  to  a^'.  These  alterations  handle  a  set  of  equivalence 
classes  of  messages  and  not  just  the  one  particular  set  of  messages.  Also,  if 
Pi'  receives  any  of  the  messages  back  from  it  will  go  ahead  and  coordi¬ 
nate  them  the  same  as  P^ . 

The  procedure  P^'  will  hold  each  rrij  (c<j<d)  it  receives.  If  any  two  of  the 
messages  come  from  different  aj's  then  deadlock  would  have  occurred  in  A 
and  the  set  of  messages  is  dropped  from  circulation.  If  all  the  messages 
come  from  the  same  address  then  deadlock  would  not  have  occurred  in  A 
and  the  messages  can  be  returned  for  processing. 

In  order  for  Pt  to  tell  where  each  message  comes  from  we  assume  that 
each  path  predicate  is  unique.  Then  for  each  coordinating  address  in  the 
cycle,  we  take  the  disjunction  of  all  path  predicates  that  define  possible 
paths  to  Uj.  i'or  example,  if  there  are  paths  from  the  mail  addresses 
. aj  to  tti  then  we  would  have  the  predicate 

Pi  i  ^P2  ■  ■  '^Pi  i- 

Pt’  can  determine  which  has  forwarded  a  message  by  checking  which 
disjunction  it  matches. 


-  85  - 


So  A'  will  drop  any  messages  that  get  deadlocked  in  A  or  that  get  stuck  in  a 
loop  in  A.  Therefore  A'  is  complete.  Also  A'  is  equivalent  to  A  since  the  same 
messages  are  handled  by  both  schemes,  both  have  the  same  mail  addresses 
and  all  messages  delivered  by  A  are  processed  in  exactly  the  same  way  by 
A'. 

The  above  proof  assumes  that  if  one  of  the  m^’s  is  submitted  then  all  will 
eventually  be  submitted.  We  do  not  consider  deadlock  caused  by  users  failing  to 
submit  all  the  required  messages.  This  is  beyond  the  control  of  the  addressing 
scheme.  For  a  scheme  with  coordination  to  be  complete  for  all  messages  we 
must  construct  the  network  such  that  there  is  at  most  one  link  (set  of  arcs  in 
one  direction)  between  any  two  coordinating  addresses  and  that  such  a  link  is 
acyclic. 

A  simple  example  of  a  complete  scheme  with  coordination  is  a  star  net¬ 
work.  The  central  routing  address  has  coordination  while  the  connected  mail 
addresses  do  not.  There  is  no  chance  of  deadlock  with  the  single  routing 
address.  Another  example  is  shown  in  Thgure  4.7.  The  three  routing  addresses 
rj.rg  and  rg  have  memory  and  coordination.  The  mail  addresses  a,, ag, 03,04  and 
O5  do  not  have  coordination. 

The  link  \Ti,rz.r^\  can  be  the  only  link  containing  the  three  routing 
addresses  and  it  is  not  cyclic.  We  are  guaranteed  that  if  messages  follow  a  path 
containing  two  or  more  of  the  routing  addresses  they  must  visit  them  in  the 
same  order.  The  connections  Oj-^rj  and  05->ri  ensure  that  Oj  and  05  can  reach 
all  the  routing  addresses.  The  mail  address  Og  reaches  rg  by  the  connection 
and  from  there  can  reach  rg.  But  we  must  also  have  the  connection 
ttg  »r  1  otherwise  may  wait  forever  for  a  message  only  Og  can  generate  If  we 
know  r^  never  needs  a  message  from  Og  we  do  not  require  this  connection.  This 
can  be  decided  when  the  scheme  is  defined  The  mail  address  ag  has  the  con- 
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Figure  4.7:  Complete  Scheme  with  Coordination 
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nections  ctg-^T'g  and  a3->ri  for  similcir  reasons  as  a^. 

We  can  see  at  this  point  why  a  link  containing  two  or  more  routing 
addresses  must  be  acyclic.  If  then  it  would  be  possible  that  a  message 

from  03  visits  first  while  a  message  from  Oj  visits  rj  first.  The  connections 
r3-*a4  and  r3-*a5  only  allow  the  mail  addresses  to  receive  messages  from  r3. 
There  is  no  need  to  worry  about  deadlock  in  this  instance. 

Coordination  allows  a  scheme  to  perform  complex  routing.  For  example,  we 
could  use  coordination  in  an  addressing  scheme  to  represent  the  communica¬ 
tion  required  between  a  journal  editor  and  the  referees  assigned  to  review 
papers.  A  single  routing  address  could  embody  the  majority  of  the  routing  logic. 
The  routing  address  could  collect  reviews  and  only  forward  them  to  the  editor 
when  all  reviews  are  received.  The  routing  address  could  also  handle  the  distri¬ 
bution  of  reminders  from  the  editor  to  ensure  that  only  those  referees  who 
have  not  yet  submitted  a  review  will  get  a  reminder.  The  message  type  and 
routing  address  definitions  for  such  a  scheme  are  given  in  Appendix  2. 

4.3.  Sezlalizability  in  Addressing  Schemes 

Serializability  is  one  of  the  primary  concurrency  issues  in  database  sys¬ 
tems  [Ullm62j.  Serializability  theory  gives  precise  conditions  under  which  tran¬ 
saction  executions  can  be  considered  correct  [BeGoB2].  Concurrency  in  a  data¬ 
base  system  means  there  are  a  number  of  possible  ways  the  execution  of  a  set 
of  transactions  can  effect  the  state  of  the  database.  We  assume  the  concurrent 
execution  of  several  transactions  is  correct  if  and  only  if  its  effect  is  the  same 
as  that  obtained  by  running  the  transactions  serially  in  some  order.  This 
notion  of  correctness  is  intuitively  appealing  since  we  are  able  to  comprehend 
the  effect  of  a  set  of  transactions  if  they  happen  one  after  the  other. 

Concurrency  is  adso  found  in  addressing  schemes.  More  than  one  message 
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may  be  in  circulation  and  processing  at  several  addresses  may  occur  at  any  one 
time.  The  overall  effect  of  this  concurrent  processing  on  the  routing  of  the 
messages  is  not  easily  determined  A  notion  of  senalizability  is  necessary  if  we 
are  to  evaluate  the  "correctness"  of  a  routing.  We  have  seen  how  the  properties 
of  memory  and  coordination  can  further  complicate  the  routings  within  an 
addressing  scheme.  A  concurrent  notion  of  correctness  must  deal  with  these 
complications  if  it  is  to  be  of  general  use  in  addressing  schemes. 

The  use  of  local  memory  at  an  address  means  the  prior  eirrival  of  one  mes¬ 
sage  can  have  an  effect  on  the  routing  of  a  later  message.  For  a  routing  to  be 
intuitively  "correct",  these  two  messages  should  be  processed  in  the  same 
order  at  all  addresses  both  messages  visit  during  the  routing.  Otherwise,  the 
routing  of  the  two  messages  is  inconsistent  among  different  paths  followed. 

A  serial  routing  is  intuitively  correct.  We  say  a  routing  .  .  .  ,m^'\  is 

serial  if  all  the  routing  for  some  is  performed  before  the  routing  of  another 
nij  We  can  comprehend  the  effects  on  the  state  of  the  communication  space  if 
the  messages  are  processed  one  at  a  time.  We  recall  that  a  routing 
.  .  .  ,m^]  can  also  be  expressed  as  a  series  of  states  Cq.Ci,  .  .  ,  Cf .  A  mes¬ 
sage  visits  address  during  R  if  there  is  some  state  Cp  in  the  series  such 
that  {a^.,Tn^)€c:)p.  The  routing  Ris  serial  if,  for  any  two  messages  and  rrij,  all 
procedure  executions  Pik  happen  before  all  procedure  executions  Pji  for  all 
addresses  visited  by  and  all  addresses  visited  by  rrij. 

Definition: A  routing  R[mi,  .  .  is  serial  if  for  any  two  messages 

Trii.mj  €  fmi,  .  .  .  ,rn^] 

(Vafc)(Vdj)(3^)(3  o7)((afce4  Aaj€.^A(afc,7rLi)ew^A 

(ai,m_,)ew7)  3  Fit  <  Pji) 

where  is  true  in  is  true  in  C,  and  Cp,  Cq  ^  [C^,  .  .  .  ,  Cj\. 

We  can  say  that  a  routing  is  correct  if  it  has  the  same  effect  as  a  serial 
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routing  of  the  same  messages.  That  is.  the  messages  are  delivered  to  the  same 
addresses  and  all  local  memories  are  left  in  the  same  state  (m  fact,  we  will 
require  that  all  the  same  procedures  be  executed  when  formally  defining 
equivalence).  Two  or  more  messages  whose  paths  intersect  at  more  than  one 
address  will  arrive  in  the  same  order  at  all  these  addresses  in  such  a  routing. 

But  this  concurrent  notion  of  correctness  is  not  suitable  for  addressing 
schemes  with  coordination.  It  is  not  possible  to  process  the  messages  serially  if 
coordination  exists  since  the  processing  of  one  message  requires  the  arrival  of 
other  messages  in  order  to  complete.  A  message  may  only  go  so  far  down  a 
path  and  then  have  to  wait  until  other  messages  arrive  but  these  other  mes¬ 
sages  cannot  be  routed  until  the  original  message  is  completely  routed.  So  we 
have  deadlock  in  the  routing. 

As  an  example  consider  the  addressing  scheme  with  the  network  in  Figure 
4.6.  The  addresses  a,  and  Ug  send  messages  to  ag  Address  Ug  pairs  up  these 
messages,  using  coordination,  and  then  alternately  transfers  both  at  once  to 
either  or  a^.  A  log  for  routing  R[m^,m2\  is  shown  in  Figure  4.9.  Messages  m, 
and  TTLg  are  submitted  to  and  ag,  respectively,  and  then  sent  to  ag.  When  both 
messages  have  arrived  they  are  sent  to  a^.  We  can  see  that  /?[mj,mg]  is  correct 
but  there  is  no  possible  serial  routing  for  and  mg  since  Pi3[]  and  Pz^[]  must 
both  execute  before  Pi4[]  and  Pz^[]- 

We  say  a  routing  is  locally  serial  if  the  order  of  processing  is  the  same  at 
all  addresses.  A  locally  serial  routing  is  still  intuitively  correct  and  accommo¬ 
dates  coordination. 

Definition  A  routing  R[mi,  .  .  .  ,m„]  is  Locally  serial  if  for  any  two  messages 

i;.  \mi,  .  .  .  ,171^1 

(Vaj)(3  a^)(3  w^)((aje4  A(aj,77T,i)ec5^A(ai,mj)ea^)  D  P^  <  Pji) 

where  cJp  is  true  in  Cp,  cJg  is  true  in  Cg  and  Cp,Cg^\Co,  .  .  .  ,Cfl. 


Figure  4.8:  Addressing  Network  for  Rtml»m2] 
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Figure  4.9:  Log  over  R[ml/m2] 
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Therefore  we  define  a  routing  to  be  correct  if  it  has  the  same  effect  as  a  locally 
serial  routing. 

We  assume  the  addressing  schemes  to  be  complete.  Thus  we  are 
guaranteed  that  every  message  routing  will  eventually  halt  and  we  will  not  face 
the  problem  of  never  finishing  a  serial  execution.  The  discussion  of  serializabil- 
ity  employs  the  concept  of  a  routing  log  as  defined  in  section  4,1.  We  first  dis¬ 
cuss  the  equivalence  of  logs  which  is  used  to  define  serializability. 

4.3.1.  Log  Equivalence 

If  Lis  a  log  over  some  routing  R[m^ . we  say  Phi[yjh\  affected  by 

and  and  there  does  not  exist  Pkjiyjk]  such 

that  Py  [  Vji  ] <Pjtj  [  ijfc  ] <P/i;  [  IjTi  ]  and  yJir^yj|gt^yjf^^lp.  In  other  words,  the  prior 
arrival  of  message  affects  the  routing  of  message  mf^  at  address  aj  and  there 
is  no  message  that  arrives  in  between  that  can  override  that  effect. 

Intuitively,  two  logs  are  equivalent  if  the  same  addresses  are  visited  by  the 
same  messages  in  each  of  the  logs  (same  state  changes  to  the  communication 
space  with  respect  to  the  individual  messages)  and  they  have  the  same  effect  (if 
any)  on  the  local  memory  of  each  of  the  addresses.  Formally,  we  say  two  logs 
are  equivalent  if  they  have  the  same  T,  and 

(1)  each  procedure  execution  is  affected  by  the  same  procedure  execution  in 
both  logs; 

(2)  they  have  the  same  set  ol  final  accesses-, 

(3)  they  have  the  same  coordination  sets. 

A  procedure  execution  Py[lji]  is  a  final  access  to  some  set  of  variables 
C:  yji  ^  if  there  is  no  P^j  [  y^k  ]  such  that  Pij  [  yjk  ]  <Pk}  [  yjk  ]  and  yjf  C  A  coor¬ 
dination  set  is  a  set  of  procedure  executions  •  •  •  ’Pki[V)  that  all  coordi¬ 

nate  on  some  message  set  at  address  a^. 
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4.3.2.  SerialLzable  Logs 

A  locally  serial  log  over  a  routing  ....  ttx^]  is  a  partial  ordering  on  £ 

such  that  for  each  pair  of  messages  Tni,mjE\mi,  .  .  .  .rrinl  and  all  addresses 
visited  by  both  and  either  Pij^  <  Pjk,  or  vice  versa.  An  example  of  a 
locally  serial  log  is  shown  in  Figure  4.10. 

A  log  is  ser-kdizahle  if  it  is  equivalent  to  a  locally  serial  log.  We  consider  the 
routing  associated  with  the  log  to  be  correct.  For  example,  the  log  over 
R[mQ,  .  .  .  ,ra^]  shown  in  Figure  4.2  is  serializable.  We  can  see  that  it  is 
equivalent  to  the  locally  serial  log  Sover  in  Figure  4.10. 

Suppose  Z,  IS  a  log  over  the  routing  R\mi,  ....  7n^\.  The  serialization  graph 
for  L,  SG(L),  is  a  directed  graph  whose  nodes  are  ,  .  ,  ,R[m^]  and  whose 

edges  are  all  R[t^\-^ R{'mj  \  such  that  for  some  set  of  variables  at  address 
visited  by  both  messages  rrit  andm^  ,  ]  and  = 

A  cycle  will  occur  in  SG(L)  if  the  routing  procedure  executions  for  a  set  of 
messages  are  in  a  different  order  at  two  or  more  addresses.  This  is  not  correct 
since  the  routings  of  two  or  more  messages  affect  each  other  in  different  ways 
on  different  paths.  So  L  can  not  be  serializable.  Figure  4.11  shows  the  serializa¬ 
tion  graph  SG(L)  for  the  log  L  of  F’igure  4.2.  There  are  no  cycles  and  we  already 
know  L  is  serializable.  The  independent  subgraphs  in  a  serialization  graph  mean 
that  individual  routings  have  no  effect  on  each  other,  eg.  Z?[mo]  and  R[Tnx\, 
A’[771o]  and  in  SG(L).  So  in  a  memoryless  scheme,  there  will  be  no  edges 

at  all  in  any  of  the  serialization  graphs  since  each  routing  is  totally  indepen¬ 
dent. 

Observation.y  or  any  addressing  scheme  A  and  log  L  over  a  routing 

R\m^ . m^]  if  SG(L)  is  acyclic  then  L  is  serializable. 
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Figure  4.10:  Locally  Serial  Log  S 
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Figure  4.11:  Serialization  Graph  SG(L) 
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Argument.yfe  will  give  a  proof  by  contradiction.  Assume  L  Is  not  serializable,  so 
by  definition  we  know  L  is  not  equivalent  to  some  locally  serial  log  S.  That 
is  one,  or  both,  of  the  following  statements  is  not  true 

(1)  every  procedure  execution  is  affected  by  the  same  procedure  execution 
in  both  L  and  51 

(2)  L  and  5 have  the  same  set  of  final  accesses. 

We  will  consider  the  two  cases  when  each  of  the  above  statements  is  false. 

case(l):  When  compared  with  every  locally  serial  log  5 over  A*  there  is  some 
Pij[Vji]  affected  by  some  in  L  that  is  not  in  S.  This  implies  there  is 

an  edge  in  SG(L). 

We  know  L  is  not  serializable  by  assumption,  so  there  must  be  some  other 
address  visited  by  both  rri^  and  such  that  P^[  conflicts  with 
PkhiVhk]  and  Pij,[Vhi]<Pkh[Vf^].  implies  there  is  an  edge 

in  SG(L)  though  this  may  be  obtained  by  transitivity.  There¬ 
fore  SG(L)  has  a  cycle  but  this  is  a  contradiction 

case (2).  When  compared  with  every  locally  serial  log  S  over  R  there  is  at 
least  one  in  the  set  of  final  accesses  of  Athat  is  not  in  5. 

If  P^j[VJ■^]  is  the  final  access  on  Vjf  in  L,  but  /*:;•[  1;^]  is  the  final  access  in  5, 
then  in  L  and  there  is  an  edge  R[7n,^]-* R\rn^^  in  SG(L), 

though  perhaps  by  transitivity,  i.e.  there  may  be  conflicting  accesses 
between  them. 

We  know  by  assumption  that  L  is  not  serializable.  So  there  must  be  some 
other  address  a^  with  variable  set  such  that  [_  J  and 

conflict,  and  Pi^^[Vhi\<Pkt^,[V^^^^].  So  there  must  be  an  edge 

R[mi]^R[m^^  in  SG(L),  though  perhaps  by  transitivity.  Therefore  SG(L)]iSi.s 
a  cycle,  but  this  is  a  contradiction. 
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Therefore  I  is  serializable  if  SG(L)  is  acyclic. 

^A.  Time  Independence  in  Addressing  Schemes 

An  addressing  scheme  is  called  time  independent  if  the  time  needed  to  pro¬ 
cess  a  message  at  each  address  does  not  affect  where  the  message  gets 
delivered  [Tsic83].  i.e.  the  final  destination(s)  for  each  message  does  not 
depend  on  the  sequence  of  applying  the  next  state  mapping  in  the  network. 

Formally,  an  addressing  scheme  is  time-independent  if  all  possible  rout¬ 
ings  for  a  set  of  messages  submitted  to  the  addresses 

^aj.  ...  ,0^1,  respectively,  eventually  deliver  the  messages  to  the  same  mail 
addresses,  and  hence  the  same  roles. 

D2finition  kn.  addressing  scheme  is  time  independent  if  for  any  state  C  of  the 
communication  space  such  that 

(3  7711,  .  .  .  ,77T^)(3ai.  .  ,ar,){[mi . 

Kai,7ni),  .  ,  .  ,  {a^.m^)lco) 

then  for  any  two  routings  Ri[mi,  .  .  .  ,7rL„  j:C->Ci  and  /?2[7n.;,  .  .  ,m^\:C-*C2 

(■V^)CWyii)(r  A(r  .77t^)gwi  {r  ,m^)ccj>2),  l<i<7i. 

Observation: Any  addressing  scheme  A  is  time  independent  if  it  is  complete  cind 
there  are  no  conflicts  at  any  of  the  addresses  in  A. 

Argument  .For  A  to  be  time  independent  we  know  that  the  amount  of  time  spent 
by  a  message  at  any  of  the  addresses  must  not  affect  the  final  destinations 
of  the  message, 

For  a  given  set  of  messages  frrio.  .  .  .  \  in  circulation,  and  two  routings 

of  the  messages  R[mi,  ,  .  .  ,  m^  ]  and  R'[mi.  .  .  .  ,  m^  ],  a  message  spends 
more  time  at  an  address  a.j  in  R'  than  in  R\i  messages  processed  after 
at  ttj  in  /?  are  processed  ahead  of  it  in  R'  (we  assume  the  time  a  message 
spends  at  an  address  is  directly  proportional  to  the  number  of  messages 
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ahead  of  it  to  be  processed), 

Jf  aj  is  memoryless  and  coordination-free  we  know  by  definition  that  each 
message  is  processed  independently.  So  the  order  of  processing  does  not 
alter  the  destinations. 

If  aj  has  memory  then  order  can  matter.  Since  the  prior  arrival  of  a  mes¬ 
sage  can  alter  memory  and  affect  the  routing  of  succeeding  messages.  But 
we  assume  there  are  no  conflicts,  so  for  any  two  executions  Pij[Vji]  and 
Pkjl^jk]  know  Vji^Vjf^  =  0.  The  memory  used  by  the  executions  does  not 
overlap  so  they  can  have  no  affect  on  each  other.  Therefore  the  order  of 
processing  does  not  alter  the  destinations. 

If  aj  has  coordination  then  again  order  does  not  matter.  The  messages  will 
be  kept  until  all  the  messages  to  be  coordinated  have  arrived  and  then  the 
set  of  messages  will  be  routed.  The  order  does  not  affect  the  routing. 

Therefore  A  is  time  independent. 
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Chapter  5 

Examples 

This  chapter  presents  two  extended  examples  to  show  the  applicability  of 
the  MMS  model.  The  first  example  discusses  a  representation  of  USENET  and  the 
Network  News,  a  bulletin  board  system  shared  among  many  computer  systems 
in  the  computer  science  community  around  the  United  States  and  Canada.  The 
second  example  is  an  artificial  one,  designed  to  emphasize  the  properties  of 
addressing  schemes. 

5. 1 .  Network  News 

USENET  (Users’  Network)  [Horton]  is  a  logical  network  sitting  on  top  of 
several  physical  networks  including  uucp,  BIJCN,  Berknet  and  the  ARPANET.  The 
sites  include  many  universities,  private  companies  and  research  organizations 
Most  members  are  either  university  Computer  Science  departments  or  part  of 
Bell  Telephone  Laboratories.  Currently,  most  USENET  sites  run  the  UNDC^ 
operating  system. 

The  network  news,  or  netnews,  is  a  set  of  programs  that  provide  access  to 
the  news  and  transfer  it  from  one  machine  to  the  next.  It  allows  articles  to  be 
posted  for  limited  or  wide  distribution.  The  level  of  distribution  is  controlled  by 
specifying  the  newsgroup. 

Any  user  can  post  an  article,  which  will  be  sent  out  to  the  network  to  be 
read  by  any  other  users  interested  in  that  topic.  A  user  specifies  the  topics  he 
or  she  is  interested  in  via  a  subscription  list.  Whenever  a  user  asks  to  read  the 
news  he /she  is  presented  with  all  the  new  articles  from  each  of  the  newsgroups 


1.  UKIX  is  a  Traderruirk  of  Bell  Laboratories 
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in  the  subscription  list.  Netnews  also  has  facilities  for  browsing  through  old 
news,  posting  follow-up  articles  and  sending  direct  electronic  mail  replies  to 
the  author  of  an  article. 

We  discuss  four  main  representation  issues  for  this  example;  newsgroups 
and  subscription  lists,  type  definitions,  netnews  commands  and  possible 
addressing  schemes. 

5.1.1.  New^roups  and  ^ibscription  Lists 

Interest  topics  on  USENET  are  called  newsgroups.  Users  subscribe  to  a 
newsgroup  in  order  to  gain  access  to  the  articles  for  that  topic.  The  set  of  news- 
groups  a  user  has  access  to  is  called  his/her  subscription  list.  The  obvious  way 
to  represent  a  newsgroup  in  our  MMS  model  is  by  a  role  -  the  articles  on  the 
topic  then  become  the  messages  owned  by  the  newsgroup  role. 

There  are  two  ways  to  relate  users  to  newsgroups  in  the  MMS  model.  The 
first  is  to  allow  the  users  to  play  the  newsgroup  roles.  Thus  the  user, 
represented  as  an  agent,  will  have  the  authority  to  play  all  the  roles  that 
appear  on  his/her  subscription  list.  When  a  user  is  doing  a  follow-up  or  posting 
a  new  article  there  is  no  explicit  communication.  The  message  is  just  inserted 
into  the  set  of  messages  owned  by  the  role.  This  is  not  a  good  representation 
because  communication  does  occur  and  should  be  captured.  USENET  is  made  to 
resemble  a  database  with  this  representation.  Another  problem  is  that,  since  a 
user  can  only  play  one  role  at  a  time,  the  representation  allows  users  to  only 
look  at  one  newsgroup  at  a  time.  This  is  not  how  netnews  functions. 

A  second,  and  more  satisfactory,  representation  is  to  give  each  user  their 
own  role,  make  the  newsgroup  roles  passive  and  let  the  user  roles  own  the 
appropriate  newsgroup  roles.  A  user  plays  only  the  one  role  but  has  access  to  all 
the  messages  owned  by  the  newsgroups  in  his/her  subscription  list  through  the 
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owns  relationship.  No  agents  play  the  newsgroup  roles  so  the  newsgroups  act 
just  as  bulletin  boards,  which  is  the  intent  of  the  system.  Users  send  messages 
to  the  newsgroup  roles  whenever  they  post  or  follow-up  an  article,  thus  the 
communication  is  explicitly  represented.  We  also  capture  the  fact  that  users 
can  reply  directly  to  another  user  without  going  through  a  newsgroup.  There  is 
no  clean  and  simple  way  to  model  changing  a  subscription  list.  We  would  have  to 
redefine  the  structure  of  the  system  every  time  by  adding  new  owns  statements 
or  removing  existing  ones. 

There  are  currently  several  categories  of  newsgroups  in  the  system: 

(1)  local  newsgroups  are  kept  on  the  current  host  only  and  identified  by  the 
lack  of  a  prefix,  eg.  general, 

(2)  ueb  groups  go  to  all  USENET  machines  at  Berkeley  and  prefixed  with  ueb, 
eg.  ueb. general] 

(3)  /“  groups  are  from  the  ARPANET; 

(4)  net  groups  are  available  to  the  whole  network 

We  will  not  include  any  relationships  between  the  different  categories  in  our 
representation.  Users  will  have  to  explicitly  own  the  appropriate  newsgroup 
roles.  This  is  because  there  is  no  overlap  among  these  newsgroups  in  the  sys¬ 
tem,  i.e.  articles  posted  in  net. general  are  not  automatically  part  of  some  local 
general  newsgroup.  These  categories  are  designed  to  restrict  distribution. 

Netnews  also  allows  subgroups  to  be  formed.  For  example,  in  the  news- 
group  net. auto,  which  contains  eirticles  of  interest  to  car  owners,  there  is  the 
subgroup  net. auto. vw.  which  is  for  Volkswagen  Rabbit  owners.  Although  it  is  not 
clear  from  the  documentation,  we  assume  that  if  a  user  subscribes  to  a  sub¬ 
group,  he /she  also  subscribes  to  the  supergroup.  We  represent  this  by  having 
the  subgroup  roles  own  their  corresponding  supergroup  roles.  A  subscriber  of 
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the  role  Tiet.aato.'mv  gets  all  the  messages  for  the  subgroup  plus  has  the  right 
to  access  those  messages  of  net. auto. 

Users  of  7ietneius  are  able  to  specify  a  distribution  to  limit  posting  to  a  par¬ 
ticular  part  of  the  net.  for  example  net. sf -Lovers  with  a  distribution  of  nj  res¬ 
tricts  the  article  to  machines  in  New  Jersey.  We  model  this  with  a  set  of 
regional  roles  that  correspond  to  the  possible  distributions  that  all  own  the 
unrestricted  newsgroup  role.  The  role  net.sf-lovers.nj  (our  notation)  would  own 
the  role  net.sf-lover  and  have  access  to  all  the  messages  with  general  distribu¬ 
tion  or  restricted  to  the  appropriate  region. 

Figure  5.1  shows  an  example  of  the  possible  relationships  between  some 
sample  roles.  The  user  "john"  resides  at  the  University  of  Toronto  and  sub¬ 
scribes  to  the  local  newsgroups  ois,  cooks  and  general  and  the  network  news- 
groups  net.oa,  net.rec.ski  and  vet. re c. scuba.  We  assume  the  distribution  would 
be  ont  for  Ontario, 

5.1.2.  Type  Definitions 

Only  four  type  definitions  are  required  to  represent  the  netneujs.  The  two 
message  types  required  are  for  articles  and  direct  replies.  Articles  are  com¬ 
posed  of  a  header,  which  contains  the  name  of  the  author  (logon  name),  the 
subject  and  the  length  of  the  article,  and  the  text  of  the  article.  We  add  three 
other  properties  to  the  article  definition:  a  newsgroup  and  a  distribution  which 
can  be  used  by  the  follow-up  command,  and  the  posting  time  to  be  used  to  qual¬ 
ify  news  searches  according  to  time.  eg.  all  articles  since  last  Thursday  on  the 
subject  "meatloaf  recipes".  The  reply  messages  contain  the  properties  subject, 
to,  a  carbon  copy  list  and  the  text  of  the  reply.  Figure  5.2  shows  the  article  mes¬ 
sage  type  definition  and  Figure  5.3  shows  the  reply  message  type  definition. 
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john 


o  I 


cooks  general  net.oa:Qnt 


net . rec- sk i : ont 


net  - r ec . scuba : ont 


net . rec : ont 


net . rec . sk i 


net . rec. scuba 


Figure  5.1:  Example  Role  Structure 
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define  message  type  Article  begin; 
properties: 

Article  Name,  Subject,  Length,  NOroup, 
Distn,  Post  Time,  Text'. 

constraints 

domain  of  Name  is  string(6); 
domain  of  Subject  is  string(25); 
domain  of  Length  is  integer; 
domain  of  NOroup  is  string(lOO); 
domain  of  Distn  is  string(lO); 
domain  of  Post  Time  is  integer; 
domain  of  Text  is  text; 

end; 


Figure  5.2:  Article  Message  Type 

define  message  type  Reply  begin; 
properties 

Reply  Subject,  To,  Text,  Cc+; 

constraints 

domain  of  Subject  is  string(25); 
domain  of  7b  is  string(6); 
domain  of  Text  is  text; 
domain  of  Cc  is  string(6); 

end; 


Figure  5.3:  Reply  Message  Type 

We  also  require  two  role  type  definitions  -  one  for  newsgroups  and  one  for 
users.  The  newsgroup  roles  are  passive  and  so  only  have  the  select  access  to 
cirticles.  This  means  that  they  can  receive  articles  but  not  create  or  modify 
them.  Newsgroups  are  not  given  any  access  to  replies  since  replies  are  only 
intended  to  be  between  users.  The  user  roles  are  given  free  access  to  both  mes¬ 
sage  types.  Figure  5.4  shows  the  newsgroup  role  type  and  Figure  5.5  shows  the 
user  role  type. 
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define  role  type  Newsgroup  begin; 
properties 

Newsgroup  ->  Name; 
constraints 

domain  of  Name  is  string(6): 
for  {Art'vcle')  include  (read); 

end; 


Figure  SM:  Newsgroup  Role  Type 

define  role  type  User  begin; 
properties 

User  ->  Logon; 
constraints 

domain  of  Logon  is  string(6): 
for  {Article)  include  (all); 
for  {Reply)  include  (all); 

end; 


Figure  5.5:  User  Role  Type 

5.1.3.  Netnews  Commands 

We  discuss  the  representation  of  the  four  most  important  commands:  read- 
news,  postnews,  follow-up  and  reply.  The  readnews  commemd  presents  the  arti¬ 
cles  not  yet  looked  at  by  a  user.  When  readnews  is  issued  the  "new"  articles 
from  each  newsgroup  the  user  subscribes  to  are  presented.  The  user  is  first 
shown  the  header  of  the  article  and  the  text  if  desired.  This  presentation  of 
parts  of  the  articles  can  be  represented  by  sets  of  select  operations  in  the 
model.  These  can  be  embedded  in  a  control  structure  to  simulate  the  proper 
execution. 

One  representation  problem  is  how  to  distinguish  the  new  from  the  old 
articles,  i.e.  those  read  from  those  not  yet  read.  One  method  is  to  define  a  pro¬ 
perty  of  the  user  role  to  record  those  articles  examined.  An  even  better 
representation  is  to  create  a  special  type  of  message  that  is  used  to  keep  track 
of  the  old  messages.  An  instance  of  this  type  is  owned  by  each  user  role  and  its 
contents  modified  whenever  articles  are  read,  This  message  is  never  communi- 
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cated;  only  referenced  and  modified. 

There  is  no  problem  with  browsing  through  old  news  since  all  messages  are 
kept  in  the  communication  base  unless  specifically  deleted.  The  model 
representation  provides  a  single  interface  to  both  new  and  old  messages,  unlike 
a  traditional  message  system  that  forces  users  to  employ  a  separate  filing  facil¬ 
ity  to  keep  messages.  We  have  also  included  the  FostTime  property  for  articles 
to  allow  selection  on  the  time  an  article  is  posted,  as  well  as  the  other  header 
information  and  the  text  of  tiie  article.  The  checknews  command  can  be 
represented  in  a  similar  fashion. 

The  postrt^us  command  is  used  to  submit  a  new  article.  The  user,  after 
issuing  the  command,  is  prompted  for  the  newsgroup,  title  and  distribution, 
and  then  allowed  to  enter  the  text  of  the  article.  We  can  represent  this  com¬ 
mand  by  a  create  operation  followed  by  a  set  of  assert  commands  to  assign 
values  to  the  properties  and  then  a  submit  operation  is  performed.  The  address¬ 
ing  scheme  will  determine  the  destination  role  for  the  article  from  the  news- 
group  and  distribution  properties. 

The  follow-up  command  posts  a  follow-up  article  to  the  same  newsgroup. 
We  can  represent  this  by  first  issuing  a  select  operation  to  obtain  the  title, 
newsgroup  and  distribution  of  the  original  article.  This  is  followed  by  a  create,  a 
set  of  asserts  and  then  a  submit  operation. 

The  T^ply  command  is  used  to  send  a  reply  to  an  article  directly  to  its 
author.  We  represent  this  command  by  first  issuing  a  create  of  a  new  instance 
of  the  Reply  message  type.  We  then  issue  a  select  to  obtain  the  subject  and 
author  of  the  original  article.  This  is  followed  by  a  set  of  assert  operations  to  fill 
in  the  properties  and  finally  a  submit  of  the  reply.  The  destinations  are  deter¬ 
mined  from  the  7b  and  Cb  properties. 
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5.1.4.  Addressing  Scheme  for  Netnews 

A  possible  addressing  scbeme  for  netTie'ws  is  shown  m  Figure  5.6.  There  is 

a  single  mail  address  for  each  user  role  (mi, mg . This  is  sufficient 

since  an  agent/ user  will  only  play  the  role  of  himself /herself.  The  newsgroup 
roles  do  not  have  any  corresponding  mail  addresses  of  their  own.  Newsgroups 
are  passive  in  our  representation  and  serve  as  logical  groupings  of  users.  When 
a  message  enters  circulation  for  a  particular  newsgroup  (plus  distribution)  its 
ultimate  destinations  are  the  mail  addresses  that  correspond  to  the  user  roles 
that  own  the  newsgroup. 

There  is  a  routing  address  (rj.rg.rg)  corresponding  to  each  machine  in  the 
network.  They  pass  messages  between  their  local  mail  addresses  and  the  rest  of 
USENET.  These  routing  addresses  must  have  memory  to  ensure  the  complete¬ 
ness  of  the  scheme.  Local  mail  addresses  communicate  with  each  other 
through  the  routing  address.  The  machines  in  the  network  can  then  be  grouped 
according  to  areas  of  distribution  or  underl3dng  physical  networks  or  some 
combination  of  these.  There  is  a  routing  address  {g i,g 2>9 3<9 4)  to  act  as  a  gate¬ 
way  for  each  group  to  the  remaining  groups.  Machines  are  not  restricted  to 
belonging  to  a  single  group,  eg.  rj  belongs  to  the  groups  g  ,  and  g^. 

Routing  knowledge  is  distributed  with  this  scheme  and  can  be  further  dis¬ 
tributed  as  desired  by  adding  routing  addresses.  This  scheme  suits  the  func¬ 
tioning  of  netnews.  Routing  in  netnews  is  transparent  compared  with  electronic 
mail  facilities  that  require  the  sender  to  specify  an  explicit  set  of  recipients 
and  perhaps  even  a  path  to  the  recipients.  Users  of  netnews  do  not  have  to 
know  all  the  users  that  will  eventually  receive  an  article  or  where  on  USENET 
they  can  be  found.  The  use  of  routing  addresses  also  allows  us  to  represent  the 
option  of  machines  limiting  the  number  of  incoming  articles  for  particular 
groups.  This  filtering  can  be  part  of  the  routing  procedure  executed  at  the 
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Figure  5.G:  Net news  Addressing  Scheme 
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address. 

5.2.  Order  Processing 

This  next  example  has  been  prepared  to  show  the  properties  of  addressing 
schemes.  We  consider  three  departments  in  a  company  -  sales,  accounting  and 
the  warehouse,  Salesmen  submit  orders  to  the  system,  Orders  go  to  both 
accounting  and  the  warehouse  simultaneously.  At  each  location  orders  are 
grouped  into  shipments  of  two  orders  each.  Accounting  generates  an  invoice  for 
each  shipment  and  forwards  the  invoice  to  the  warehouse  and  the  salesman. 
While  the  invoice  is  being  prepared,  the  warehouse  fills  the  orders  and  packages 
the  shipments.  When  the  invoice  for  the  shipment  arrives  at  the  warehouse  a 
copy  is  attached  to  the  goods  and  the  shipment  delivered. 

Figure  5.7  shows  the  addressing  scheme  network  for  the  order  processing 
example.  There  are  three  salesmen  mail  addresses  (51,52,53)  connected  to  the 
routing  address  r^.  The  salesmen  submit  their  orders  from  these  addresses  and 
the  orders  go  to  where  they  are  forwarded  to  the  routing  addresses  and  rg. 
Routing  address  also  receives  the  invoices  from  Tq  and  forwards  it  to  the 
appropriate  salesman  mail  addresses. 

The  accounting  department  is  represented  by  the  subnetwork  agj. 

The  incoming  orders  are  grouped  into  shipments  by  and  then  alternately 
routed  to  one  of  the  mail  addresses  ay  or  ag.  The  orders  are  processed  and  the 
invoices  submitted  from  the  mail  addresses  and  forwarded  to  rg  which  in  turn 
forwards  them  to  rg. 

The  warehouse  is  represented  by  the  subnetwork  ^rg,  u)q,  tuio,  it'll- 
The  incoming  orders  are  grouped  into  shipments  by  rg  and  alternately  routed 
to  one  of  the  mail  addresses  lUg,  imio  or  lOn.  The  incoming  invoices  are  for¬ 
warded  by  rg  to  and  the  mail  address  vdiz-  The  address  type  definitions  and 
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Fiaure  5.?:  Address  ins  Scheme  for  Order  Processing 
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accompanying  routing  procedures  for  the  three  routing  addresses  are  given  in 
Figures  5.8  through  5.10.  We  assume  is  of  type  Sal2 Routing ,  is  of  type 

/k:ctRmxting  and  Tq  is  of  t3^e  Warp. Routing. 


define  address  type  SalesRouting  begin 
properties; 

SalesRouting  -»  Addressid; 

constraints: 

domain  of  Addressid  is  string(6); 
routing: 

instance  variable  count  integer; 
instance  variable  prevmsgs  ( 500)  integer; 
begin; 

case  (type  is  Order)  begin; 
if  current. yd  \n  prevmsgs  then 
drop  current; 
end; 
else; 

prevmsgs  (count)  current. /d; 
count  count  +  1; 
share  current  with  r5; 
forward  current  to  r6; 
end; 
end; 

case  (type  is  Invoice)  begin; 
if  current. 5iiZes Man  =  "Brown"  then 
forward  current  to  s 
else; 

if  current. 5aiesman  =  "Smith"  then 
forward  current  to  sS; 
end; 

else  forward  current  to  s3; 
end; 
end; 
end; 

end 


Figure  5.8:  SalesRouting  Address  Type 
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deflne  address  type  Ac ct Routing  begin 
properties: 

Ac  ct  Routing  -*  Address  Id; 

constraints: 

domain  of  Addressld  is  string(6); 
routing: 

instance  variable  save  reference; 
instance  variable  count  integer; 
Instance  variable  svuitch  integer; 
begin; 

caise  (type  is  Invoice)  begin; 

forward  current  to  t6; 
end; 

case  (type  is  Order)  begin; 
if  count  =  0  then 
save  <-  current; 
count  <-  1; 
end; 
else; 

If  switch  =  0  then 
forward  current  to  a7; 
forward  soi/e  to  a7; 
end; 
else; 

forward  current  to  ad; 
forward  sai;e  to  ad; 
switch  *-  0: 
end; 

count  <-  0; 

end; 

end; 

end; 

end 


Rgure  5.9:  Ac  ct  Routing  Address  Type 


-  113- 


definc  address  type  Warp.  Routing  begin 
properties: 

Ware  Routing  Aektressld; 

constraints: 

domain  of  Addressld  is  string(6); 
routing: 

instance  variable  save  reference; 
instance  variable  count  integer; 
instance  variable  swif.ch  integer; 
variable  addrmme  slring(6); 
begin; 

case  (type  is  Invoice)  begin; 
share  current  with  w  1 2; 
forward  current  to  r4: 
end; 

case  (type  is  Order)  begin; 
if  count  -  0  then 
save  <-  current; 
count  <-  1; 
end; 
else; 

if  svuitch  =  0  then 
addname  <-  '’w9''; 
svMch  <-  1; 

end; 

else; 

if  switch  ~  1  then 
addname  "wIO”; 
switch  <-  3; 

end; 

else; 

addname  <- 
switch  ^  0; 

end; 

end; 

forward  save  to  addname; 

forward  current  to  addname ; 
count  <-  0; 
end; 
end; 
end; 
end 


figure  5.10:  Ware  Routing  Address  Type 
The  addressing  scheme  discussed  has  several  cycles  in  the  network,  for 

example  r4  -  -  r0  or  ay  -  r^.  We  can  ensure  that  the  addressing  scheme  is 

complete  if  we  define  each  routing  address  with  local  memory.  The  routing 
addresses  can  then  check  for  loops  in  the  routings.  The  routing  procedure  in 
figure  5.8  shows  how  loops  can  be  detected  with  an  array  in  memory 
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{prevTnsgs)  to  keep  track  of  messages  visiting  the  address. 

The  addressing  scheme  is  not  Lime  independent  because  of  the  alternating 
of  destinations  done  b}/  and  vq.  The  alternating  at  each  address  is  accom¬ 
plished  by  checking  a  local  switch  in  memory.  Executions  of  these  procedures 
conflict,  hence  the  scheme  cannot  be  time  independent.  We  could  remove  the 
conflicts  by  merging  the  two  addresses  ay  and  ag  into  a  single  mail  address  a' 
that  corresponds  to  a  role  that  can  be  played  by  agents  that  previously  played 
either  of  the  roles  corresponding  to  or  ag.  A  similar  change  has  to  be  made 
to  the  warehouse  department,  i.e.  merge  u>q,  Wiq  and  ttin  into  a  single  mail 
address  'iv'.  Such  a  scheme  is  shown  in  Figure  5.11. 

A  set  of  routings  in  the  scheme  will  obviously  be  incorrect  if  the  messages 
are  processed  in  different  orders  at  and  rg.  Different  shipment  groupings 
may  result  and  the  invoices  produced  by  accounting  will  not  correspond  to  the 
goods  gathered  in  the  warehouse.  Figure  5.12  shows  a  log  Lx  over  a  routing 
.  .  .  , mg]  where  the  five  messages  are  four  order  messages  and  an 
invoice.  The  serialization  graph  SG{Li)  is  shown  in  Figure  5.13  and  we  can  see 
Lx  is  not  serializable.  The  serialization  graph  contains  a  cycle.  The  routing  is 
incorrect  because  the  orders  2  and  3.  and  the  orders  1  and  4  are  grouped  into 
shipments  by  accounting,  while  the  warehouse  groups  orders  1  and  2,  and  3  and 
4  into  shipments.  The  invoices  will  not  correspond  to  the  goods. 

Figure  5.14  shows  a  log  1. 2  over  a  different  routing  5'[mi,...m5j  for  the  same 
set  of  messages.  The  serialization  graph  for  L2  is  shown  in  Figure  5.15  and  we 
can  see  that  Lg  is  serializable.  The  messages  are  grouped  into  the  same  ship¬ 
ments  at  both  accounting  and  the  warehouse. 


o 


Fisure  5.11:  T i me- In depen dent  Address  ins  Scheme 
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Figure  5-lZ:  Routing  Log  LI 
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R[m5] 


Figure  5.13:  Serialization  Graph  for  LI 
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Figure  5.14:  Routing  Log  for  L2 
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Figure  5.15:  Serialization  Graph  for  L2 
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Chapter  6 

Supporting  a  Message  Management  System 

This  chapter  discusses  the  features  of  a  physical  architecture  to  support  a 
message  management  system,  and  the  mapping  from  the  MMS  model  to  that 
architecture. 

There  are  several  characteristics  of  a  MMS  that  influence  the  design  of  a 
supporting  architecture.  One  characteristic  is  the  ability  to  impose  user- 
deflned  structure  on  message  contents,  i.e.  message  types.  This  means  that 
data  base  facilities  must  be  provided  by  the  supporting  architecture. 

Another  characteristic  is  the  variety  of  data  that  can  compose  a  message  - 
text,  attributes,  voice  or  picture.  The  filing  system  must  be  designed  to  handle 
the  different  data  types  (for  example  Tsichritzis  et.al.  [TCEF83]).  This  variety 
also  means  that  a  set  of  communication  protocols  must  be  available  to  transfer 
the  different  data  types. 

A  third  characteristic  is  the  freedom  a  MMS  provides  for  organizing  and 
storing  messages.  The  use  of  dossiers  and  other  kinds  of  aggregate  message 
types  must  be  supported  by  the  filing  system. 

Another  characteristic  is  shared  ownership  of  messages.  The  physical 
architecture  must  provide  coordination  of  access  from  distributed  sites  and 
maintenance  of  consistent  duplicates  to  simulate  a  single  logical  message  for 
all  owners.  This  kind  of  facility  is  currently  found  in  distributed  data  base  sys¬ 
tems  .  I 

A  message  management  system  is  a  d5mamic  environment.  The  supporting 
system  must  provide  mobility  for  users.  They  should  be  able  to  access  their 
messages  from  any  physical  location  in  the  system.  A  MMS  is  also  very  flexible. 
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Role  changing  allows  users  a  large  degree  of  freedom  in  the  messages  they  can 
access. 

Another  characteristic  is  that  an  office  is  not  an  isolated  entity.  There  are 
always  connections  to  other  offices  both  within,  and  outside,  the  organization. 
The  physical  architecture  must  be  easily  expanded  and  make  internetworking 
as  transparent  as  possible.  It  is  possible  that  both  local  area  networks  and 
long-haul  networks  may  be  used  to  support  a  MMS.  Finally,  there  most  likely  will 
be  a  veiriety  in  the  makeup  of  the  stations  or  sites  in  the  supporting  network.  A 
station  could  correspond  to  a  personal  workstation,  to  a  large  machine  that  ser¬ 
vices  several  users,  or  to  some  kind  of  server.  There  will  also  certainly  be  a 
mixture  in  the  manufacturers  that  supply  the  stations. 

6.1.  The  Architecture 

The  ISO  Reference  Model  for  Open  System  Architecture  (OSA)  [TaneSl]  is 
now  widely  accepted  as  a  conceptual  description  of  distributed  systems.  It  is 
based  on  seven  layers  where  the  lower  three  layers  correspond  to  the  transmis¬ 
sion  of  packets,  and  defined  with  the  long-haul  network  in  mind.  When  applied 
to  systems  based  on  local  area  networks  the  hierarchy  of  communication 
remains  but  the  internal  logic  of  the  lower  three  levels  is  different  [NaffBl]  (see 
Rgure  6.1). 

Local  area  networks,  such  as  Token  Rings  [Farb75j  and  CSMA-CD  bus 
[MeBo76j.  do  not  have  an  intermediate  node  which  performs  the  switching. 
Each  site  connected  to  the  network  will  execute  this  function  by  filtering  the 
crossing  packets  if  addresses  match,  and  transmitting  packets  when  they  can 
access  the  network. 

Starting  from  the  transport  protocol,  and  moving  upwards,  a  MMS  can  be 
built  with  the  seime  higher  protocols  over  a  long-haul  network,  or  a  local  area 
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network,  or  local  area  networks  connected  through  long-haul  networks.  We 
briefly  describe  the  communication  in  each  of  the  four  higher  layers. 

The  transport  layer  allows  for  the  creation  of  a  unique  and  universal  inter¬ 
face  for  the  higher  levels.  It  masks  the  differences  between  the  networks  that 
are  used  and  must  support  the  different  session  types  provided  by  the  layer 
above  it. 

The  sesswn  layer  deals  with  the  establishment  of  logical  relations  between 
application  processes,  the  maintenance  of  these  relations,  and  dialogue  con¬ 
trol.  ITie  session  layer  masks  the  geographical  distribution  of  communicating 
application  processes.  Different  session  types  are  required  besides  the  usual 
point-to-point  communication.  A  MMS  requires  group  communication  for  mes- 
ScTige  sharing  and  distribution.  \  multicast  session  would  not  be  considered  com- 
p'ete  until  a  message  is  transferred  to  all  the  recipients’  physical  locations. 

The  presentation  layer  deals  with  physical  message  structuring  and 
transfer.  Protocols  for  structuring  voice,  text,  pictures  and  records  are  all 
required  of  this  level  by  a  MMS. 

In  the  ISO  Reference  Model  framework,  roles,  addresses  and  stations  are 
applicalum\ci.yer  entities.  As  shown  in  Figure  6.2  the  application  layer  is  further 
divided  into  the  role,  address  and  station  sublayers.  The  role  sublayer  is  the 
uppermost  sublayer.  It  is  concerned  with  the  processing  that  agents  perform 
when  they  play  a  role.  Communication  occurs  between  roles  at  this  level.  The 
role  sublayer  uses  the  address  sublayer  to  carry  out  its  communication 

The  address  sublayer  corresponds  to  communication  carried  out  in  the 
addressing  scheme  of  the  MMS.  The  addressing  scheme  delivers  a  message  for  a 
role  by  transferring  it  to  the  set  of  mail  addresses  that  correspond  to  the 
receiving  roles.  The  addressing  scheme  determines  the  receiving  roles  in  a  dis¬ 
tributed  (logically)  and  procedural  manner.  Each  step  of  the  logical  routing  is 
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represented  as  a  communication  between  addresses. 

The  address  sublayer  in  turn  uses  the  station  sublayer  to  perform  com¬ 
munication  between  addresses.  The  one  logical  step  in  the  routing  may  involve 
one  or  more  steps,  or  communications.  In  the  station  layer  as  the  physical  mes¬ 
sage  is  moved  along  the  supporting  network.  A  physical  message  is  a  logical 
message  (i.e.  a  message  as  defined  in  MM.S  model)  plus  an  envelope,  The  infor¬ 
mation  on  the  envelope  is  used  in  the  station  sublayer  communication  and  is 
not  necessarily  available  in  the  higher  sublayers. 

The  station  sublayer  must  provide  a  directory  function  to  map  each  logical 
address  to  a  physical  address.  .4  physical  address  is  the  destination  of  the  mes¬ 
sage  in  the  supporting  network.  A  likely  specification  of  a  physical  address  is  a 
(station,  mail  slot)  pair.  The  directory  function  can  be  performed  in  a  distri¬ 
buted  manner  so  that  the  entire  path  of  a  physical  message  need  not  be 
specified  at  once. 

This  division  of  the  application  layer  into  sublayers  is  similar  to  that  of 
Mulvenna  [Mulv82].  There  the  communication  in  a  CBMS  application  is  seen  to 
divide  the  application  layer  into  the  User  Agent  sublayer  and  the  Message 
Transfer  sublayer  (Chapter  2  contains  a  description  of  the  CBMS  model).  These 
two  sublayers  correspond  to  our  role  and  station  sublayers,  respectively.  We 
have  included  the  address  layer  in  the  MMS  application  to  provide  for  the  logi¬ 
cal  routing  of  the  addressing  scheme  that  is  missing  from  CBMS  models. 
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Chapter  7 

Conclusions 

7.1.  Summary  and  Contributions  of  Thesis 

This  thesis  has  investigated  a  new  t3^8  of  computer  system  and  presented 
a  model  for  systems  of  this  type.  A  message  management  system  combines  the 
facilities  of  both  computer-based  message  systems  and  data  base  management 
systems  into  a  single  system  that  can  both  manage  and  communicate  informa¬ 
tion.  This  integration  of  technologies  is  one  of  the  major  tasks  in  office  infor¬ 
mation  systems  research.  Our  model  makes  a  significant  contribution  to  this 
effort.  We  believe  message  management  systems  will  prove  to  be  a  key  com¬ 
ponent  of  office  information  systems  and  the  work  in  this  thesis  lays  the  foun¬ 
dation  for  the  understanding  and  construction  of  message  management  sys¬ 
tems. 

The  model  introduced  here  provides  a  framework  for  the  design  and  imple¬ 
mentation  of  MMS's,  It  also  serves  as  a  conceptual  model  for  the  user  in  the 
same  way  data  models  serve  the  users  of  DBMS’s.  The  model  can  be  used  to 
represent  both  message  and  data  base  systems.  It  is  unique  in  that  it  applies 
semantic  data  modeling  techniques  to  the  representation  of  message  systems. 

The  model  imposes  structure  on  the  contents  of  messages.  This  structure 
allows  the  system  to  interpret  and  use  the  contents.  Previous  work  has 
represented  messages  as  a  header  plus  a  body.  The  number  of  fields  of  the 
header  was  fixed  and  the  body  played  no  part  in  the  handling  of  the  message. 
This  meant  that  message  systems  were  restricted  in  their  processing  of  the 
messages.  The  introduction  of  message  types  lifts  these  restrictions  while  still 
allowing  us  to  abstract  the  messages  and  only  consider  the  number  of  different 
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types  rather  than  all  the  individual  messages. 

Our  MMS  model  represents  the  notion  of  the  scope  of  a  message.  In  CBMS's, 
messages  usually  have  a  ivell-defined  target.  But  target  has  a  temporary  nature 
in  that  once  a  message  is  delivered  it  loses  its  significance.  A  MMS.  because  of 
its  data  base  side,  has  a  more  permanent  nature.  Messages  are  both  communi¬ 
cated  and  stored.  'Hius  the  scope  of  a  message  has  an  existence  beyond  the 
delivery  of  a  message.  To  ensure  flexibility  we  allow  the  scope  of  a  message  to 
be  dynamically  evaluated  based  on  the  contents  of  the  message  and  the  state  of 
the  system. 

In  our  MMS  model  we  use  the  notion  of  logical  address  and  role  to  provide 
an  abstract  representation  of  the  naming  and  addressing  problem.  They  give 
flexibility  in  assigning  users  to  physical  locations.  Communication  is  between 
roles  rather  than  users  so  it  will  not  be  disrupted  if  people  change  jobs  or  the 
composition  of  groups  change.  Roles  also  reflect  the  fact  that  people  often  per¬ 
form  several  different  tasks  and  require  separation  of  these  different  sets  of 
communication.  Addresses  are  logical  so  users  changing  their  physical  location 
will  not  force  changes  in  the  addressing  scheme,  only  in  the  mapping  of  logical 
to  physical  address. 

The  MMS  model  represents  the  notion  of  ownership.  In  a  CBMS  the  sender 
initially  owns  a  message  and  transfers  the  ownership  to  the  receiver.  In  a  DBMS 
information  is  owned  by  the  data  base  which  allows  access  to  the  users.  A  MMS 
is  closer  to  a  CBMS  in  that  we  view  messages  as  being  owned  by,  or  local  to,  par¬ 
ticular  roles  but  we  allow  the  notion  of  "shared”  or  "common"  ownership  of  a 
message  among  several  roles,  Within  this  framework  the  global  view  of  a  DBMS 
IS  a  special  case. 

Associated  with  ownership  is  the  specification  of  access  rights.  These  are 
included  in  the  role  cind  message  type  definitions  and  are  used  to  control  the 
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users'  access  to  the  messages.  Access  rights  can  bo  specified  with  either  the 
role  or  the  message  type.  This  means  a  particular  role  does  not  have  to  know 
about  every  message  type.  The  rights  can  accompany  a  message  when  it  is 
delivered.  This  provides  a  great  deal  of  flexibility.  New  message  types  can  be 
defined  without  changing  all  the  role  type  definitions. 

Our  MMS  model  provides  abstraction  mechanisms.  Generalization,  aggrega¬ 
tion  and  classification  are  suitable  for  defining  message  types  or  cleisses  similar 
to  the  data  classes  of  the  semantic  data  models.  Cover  aggregation  is  used  to 
define  such  things  as  dossiers.  Messages  in  our  model  can  contai.n  other  mes¬ 
sages  and  can  be  communicated  together. 

Our  model  also  allows  the  automatic  routing  and  processing  of  messages 
using  routing  procedures  and  triggers  respectively.  We  have  seen  that  these 
facilities  are  mandatory  for  an  office  information  system.  The  system  must  be 
"intelligent"  enough  to  act  on  its  own  when  certain  situations  arise. 

We  provide  operations  from  both  the  CBMS  and  the  DBMS.  Users  are  able  to 
send,  receive,,  acknowledge  and  reply  to  messages  as  well  as  retrieve,  create, 
destroy  and  modify  messages. 

Our  MMS  model  shares  similarities  with  previous  message  system  models. 
One  similarity  is  the  separation  of  circulation  and  manipulation  functions.  Cir¬ 
culation  functions  arc  carried  out  by  the  addressing  scheme  within  our  model 
and  within  the  Message  Transport  System  in  other  models.  The  manipulation  of 
messages  is  performed  within  the  context  of  a  role  in  our  model  and  by  User 
Agents  in  other  models.  While  our  model  represents  both  of  these  functions, 
message  system  models  have  considered  the  manipulation  function  to  be  out¬ 
side  their  consideration  and  provided  by  a  different  facility  from  the  circulation 
function.  Our  model  presents  an  integrated  strueture  and  a  single  interface  for 
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A  second  important  aspect  of  our  work  is  the  study  of  communication. 
Communication  is  vital  to  message  management  systems  but  it  has  not 
received  the  same  amount  of  attention  as  data  management.  Previous  work 
has  not  attempted  a  formal  specification  of  the  properties  of  communication 
within  a  message  system  at  the  level  of  abstraction  in  this  thesis.  Most  research 
has  centered  around  the  protocol  layers.  ¥e  consider  communication  at  the 
conceptual  level. 

The  notion  of  ownership  is  key  to  the  representation  of  communication. 
We  view  the  act  of  communicating  as  a  change  in  the  ownership  of  the  message 
involved.  We  defined  different  types  of  ownership  -  private,  shared  and  common 
-  euid  are  able  to  represent  the  communication  that  takes  place  in  both  mes¬ 
sage  systems  and  data  base  systems.  Ownership  is  also  used  in  the  formal 
specification  of  the  semantics  of  communication  within  our  model.  We  are  able 
to  define  a  set  of  relationships  that  capture  ail  the  properties  of  communica¬ 
tion  and  then  define  a  set  of  axioms  in  the  predicate  calculus  that  must  be  true 
of  an  allowable  state  of  the  model.  The  effects  of  the  operations  on  the  states 
are  specified  in  terms  of  the  before  and  after  states  for  each  of  the  operations. 

The  third  important  aspect  of  our  work  concerns  the  routing  of  messages 
We  employed  addressing  schemes  as  an  abstract  framework  for  dynamic  rout¬ 
ing.  Addressing  schemes  allow  us  to  represent  a  wide  variety  of  possibilities: 
central  or  distributed  evaluation  of  the  routing;  broadcast,  individual  or  group 
addressing;  address  or  message  logic.  We  analyze  three  important  properties  of 
addressing  schemes;  completeness,  serializability  and  time-independence. 

Completeness  means  that  a  scheme  is  guaranteed  to  eventually  deliver  all 
messages  We  found  that  one  basic  requirement  for  completeness  is  that  the 
routing  procedures  must  alw.iys  halt  and  we  specified  when  this  is  the  case.  For 
a  memoryless  scheme  there  can  not  be  any  cycles  in  the  network.  We  found 
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that  memoryless  schemes  must  be  very  restricted  if  they  are  to  be  complete. 
The  inclusion  of  memory  means  that  there  may  be  cycles  in  the  network  but 
these  must  contain  an  address  with  memory.  Coordination  on  addresses  intro¬ 
duces  the  possibility  of  deadlock.  This  can  be  avoided  if  the  network  is  con¬ 
structed  in  such  a  way  that  either  coordinating  addresses  are  on  separate  paths 
of  a  message  to  be  coordinated,  or  if  coordinating  addresses  are  on  the  same 
path  for  two  or  more  messages,  each  of  these  messages  must  visit  the 
addresses  in  the  same  order. 

Serializability  serves  as  a  notion  of  the  correctness  of  a  routing  This  is 
necessary  because  of  the  concurrency  in  message  management  systems.  We 
are  able  to  borrow  work  from  serializability  in  data  bases  and  apply  it  to 
addressing  schemes.  The  important  difference  is  the  concept  of  local  serializa¬ 
bility.  Messages  must  be  treated  in  the  same  order  at  common  addresses.  This 
guarantees  that  messages  will  be  treated  in  the  same  order  at  all  addresses. 
Our  second  example  in  Chapter  5  shows  why  serializability  is  useful.  We  are  able 
to  see  that  messages  treated  the  same  way  along  each  of  the  different  paths 
they  follow  are  routed  correctly. 

The  final  property  of  addressing  schemes  we  considered  was  time- 
independence.  This  assures  that  the  time  spent  in  circulation  will  not  affect 
the  final  destinations  of  a  message.  This  is  only  true  if  the  routing  of  a  message 
can  not  be  affected  by  the  prior  arrival  of  another  message,  that  is  there  are  no 
conflicts.  This  property  can  not  be  guaranteed  in  any  addressing  scheme  with 
memory  that  uses  the  memory  to  route  the  message  to  some  part  of  a  set  of 
potential  destinations. 

7.2.  Further  Work 

The  most  important  follow-up  work  to  this  thesis  will  be  the  design  and 
implementation  of  a  message  management  system  along  the  lines  described. 
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The  ultimate  proof  of  any  work  done  in  computer  systems  research  is  the  final 
running  system.  The  construction  of  a  message  management  system  will  face 
several  problems. 

One  problem  is  shared  ownership.  This  concept  is  not  found  in  current 
message  S3^tem3.  Solutions  to  this  problem  will  likely  be  found  in  the  work  on 
distributed  data  base  systems.  Aggregate  messages  pose  unique  problems  in 
message  management  systems.  There  are  a  set  of  conditions  that  must  be  met 
before  these  messages  can  be  manipulated.  The  system  has  to  enforce  these 
conditions.  Ownership  is  also  complicated  by  the  relationships  that  can  exist 
between  roles. 

Another  problem  is  the  distribution  of  the  "schema"  for  the  message 
management  system.  Message  type  definitions  can  be  given  to  all  stations  that 
will  come  in  contact  with  messages  of  those  t3q5es.  But  new  messages  should  be 
allowed  to  introduce  their  type  definitions  to  stations.  This  would  reduce  the 
amount  of  definitions  a  station  has  to  know  just  in  case  a  message  of  a  certain 
type  may  arrive. 

Another  implementation  problem  concerns  controlling  access  to  the  com¬ 
munication  base.  The  introduction  of  type  hierarchies  for  roles  complicates  the 
determination  of  access  rights  for  a  role.  Also  access  rights  may  accompany  a 
message  and  may  increase  the  rights  of  a  role. 

Addressing  schemes  are  another  area  for  further  reseeu'ch.  These  are  the 
most  unique  part  of  a  message  management  system  and  will  present  new  prob¬ 
lems  besides  those  similar  to  the  problems  encountered  in  distributed  data 
base  systems.  Addressing  schemes  are  a  new  concept  They  should  be  applied  to 
a  wide  variety  of  existing  systems  to  gain  further-  insights  and  understanding. 
Very  complicated  routings  can  be  achieved  using  memory  and  coordination. 
More  study  is  needed  to  better-  understand  the  effects  of  these  properties. 
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Message  logic  addressing  schemes  are  another  area  that  require  more 
investigation.  There  are  only  a  handful  of  "intelligent"  message  systems  in 
existence,  or  being  contemplated,  but  their  future  importance  to  office  infor¬ 
mation  systems  is  recognized.  The  properties  of  message  logic  schemes  should 
be  studied  in  greater  detail  as  more  instances  of  these  systems  arise. 
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Appendix  1 


Sp>ecification  of  the  MMS  Model  Language 


'the  specificatLon  uses  the  following  syntactic  notation: 

[item]  denotes  zero  or  more  repetitions  of  the  item; 

[item]  denotes  that  the  item  is  optional. 

Keywords  and  specied  characters  are  given  in  boldface.  Nonterminals,  eg. 
CbSchema,  are  given  in  italics.  The  symbol  Empty  denotes  the  null  string. 

The  definition  of  a  message  management  system  is  given  by  a  Ct) Schema, 

which  IS 

\  Mess  age  7]/pe| 

\B}leTypel, 

\AddressType] 

{Relationship] 

[  Trigger] 

A.  MessageType  is 

define  messeige  type  Name  begin 
[  Property  Section] 

[  Cons  tituentSec  tion\ 

[  Mapping  Se  c  tion  j 
i  Constraints  Sec  tion] 

[  Routing  5fe  c  tion] 
end 

Each  MessageType  defines  a  class  of  possible  messages  within  the  system.  The 
members  of  the  class  all  have  similar  properties  and  behaviour.  A  MessageType 
with  no  sections  defines  a  class  of  messages  that  consist  only  of  an  identifier. 
The  routing  section  is  given  if  the  message  routing  is  performed  by  a  message 
logic  addressing  scheme 

A  Property  Sec  tion  is 

properties: 

Name  ”»  {Property Name  .]  Proper ty Name , 

The  Property  Section  associates  a  set  of  properties  or  attributes  with  the  name 
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of  the  type  being  defined 

A  PropertyName  is  one  of 

a.  Namxi 

b.  NaT7w.+ 

The  symbol  following  a  Name  indicates  a  multivalued  property. 

A  CoTistituentsSection  is 

constituents: 

Name  ->  [Constituent  Name  Constituent  Name] 

The  ConstituentsSection  is  used  to  define  aggregate  message  types.  It  associ¬ 
ates  a  list  of  constituent  names  with  the  type  name.  Constituents  of  the  aggre¬ 
gate  must  correspond  to  these  names  and  be  of  the  defined  types. 

A  Constituent  Name  is  one  of 

a.  Name 

b.  Name-r 

The  symbol  "-t-"  following  a  Name  indicates  that  more  than  one  constituent  is 
associated  with  the  single  name. 

A  Mapping  Section  is 
mapfMngs: 

[Name  :  Name  ->  Name\\ 

The  Mapping  Section  is  used  to  establish  relationships  between  a  type  and  its 

constituents.  For  example  consider 

define  message  type  Dossier  begin 
properties: 

Dossier  -»  Title-, 
constituents: 

Dossier-^  Contents+, 
mappings: 

ContainedJn.:  Contents  ->  Dossier, 

Contains:  Dossier  -»  Contents] 

constraints: 

domain  of  Title  is  strmg(25); 
domain  of  Contents  is  Memo-. 
end 

Each  instance  of  the  aggregate  message  type  Dossier  can  contain  a  set  of  mes- 
seiges  of  type  Memo.  The  contents  are  related  to  the  instance  of  Dossier  by  the 
relationship  Containedln.  Similarly,  the  relationship  Contains  maps  an  instance 
of  Dossier  to  the  instances  of  Memo  that  it  contains.  It  is  also  possible  for  an 
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aggregate  to  have  properties  separate  from  any  constituents.  The  property  TUle 
corresponds  to  a  label  on  a  file  folder. 

A  Cons traints Section  is 

constraints; 

\  domain  of  Name  is  DomainNcune ;  j 
^for  Name  include  {Right), \ 

The  Constraints  Section  defines  the  domain  or  type  of  each  property  and  consti¬ 
tuent.  Access  rights  are  also  specified  in  this  section.  When  the  access  rights 
are  defined  with  a  message  type,  the  rights  are  associated  with  a  set  of  role 
type  names.  Instances  of  the  message  type  will  grant  these  rights  to  any 
instances  of  the  specified  role  types  that  receive  them.  When  the  access  rights 
are  defined  with  a  role  type,  the  rights  are  associated  with  a  set  of  message  type 
names.  Ail  instances  of  the  role  have  the  defined  rights  to  instances  of  the 
specified  message  types. 

A  DomainName  is  one  of 

a.  Type  Name 

b.  Name 

A  Type  Name  is  one  of 

a.  integer 

b.  reference 

c.  text 

d  string{AAi77i,5er) 

These  are  the  basic  data  t3^es  defined  for  the  model.  The  type  reference  is  used 
to  provide  pointers  to  message  instances.  We  would  also  like  to  see  such  data 
types  as  audio  and  picture  in  an  office  environment. 

A  Mght  is  one  of 

a.  Access 

b.  Right,  Access 


An  Access  is  one  of 
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a.  read 

b.  send 

c.  create 

d.  destroy 

e.  copy 

f.  modify 
g  all 

The  all  means  that  all  rights  are  included. 

A  Hoteli/pe  is 

define  role  type  Name  begin 
Property  Sec  tion 
Constraints  Section 

end 

A  Roletype  defines  a  class  of  roles  with  similar  properties.  The  property  and  con¬ 
straints  sections  are  not  optional.  Roles  are  not  given  system-assigned 
identifiers.  We  require  the  user  to  specify  some  identifying  property  and  its 
associated  domain. 

NciAddressType  is 

define  address  type  Name  begin 
Property  Sec  tion 
AddConstSs  c  tion 
[Pbuting  Sec  tion] 

end 

An  AddressType  defines  a  class  of  addresses  with  similar  properties  and 
behaviour.  The  property  and  constraints  sections  are  required.  The  routing  sec¬ 
tion  is  present  if  address  logic  is  used  to  route  the  messages. 

An  AddConst Section  is 

constraints: 

^domain  of  Nome  is  Domain  Name,] 

A  Pouting  Sec  tion  is 

routing: 

Procedure 

A  Procedure  is 

Declaration 

Body 

A  Procedure  embodies  a  portion  of  the  routing  logic  of  a  MMS.  Each  execution  of 
a  procedure  performs  a  step  in  the  routing  of  a  message.  Each  procedure  is 
composed  of  a  set  of  declarations  and  a  body. 
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A  Declaration  is 

J  Variable  Declaration] 

I  \j[nstanceVariableDeclarat.iQn\ 

The  declarations  in  a  procedure  are  of  two  types.  Variable  declarations  are  used 
to  define  variables  that  are  reinitialized  at  the  start  of  every  execution. 
Instance  variable  declarations  define  local  memory.  These  variables  exist 
between  executions  and  retain  their  values. 

A  Variable Declaratian  is 

variable  Variable  Name  Vijpename  , 

An  Instance  Variable  Declaration  is 
instance  variaWe  Variable  Name  TypeName, 

A  VariableName  is  one  of 

a.  Name 

b.  Name{NumJber) 

A  Body  is 

begin; 

ICbse j 
end; 

A  routing  procedure  body  is  just  a  series  of  cases.  The  most  appropriate  case  is 
chosen  and  the  associated  actions  performed. 

A  Case  is 

ceise  {Case Expression')  begin; 

{Statement] 

end; 

A  CajseExpressixm  is  one  of 

a.  type  is  Name 

b.  type  is  one  of  (  Name  j ,  Name  j  ) 

c.  address  is  Name 

d.  address  is  one  of  (  Name  J ,  Name  ) 

e.  Empty 

In  address  logic  schemes,  cases  are  determined  by  message  types.  In  message 
logic  schemes,  cases  are  determined  by  the  current  address,  hn  empty  or  null 
Case  Expression  signifies  the  default  case. 


A  Statement  is  one  of 
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a.  IfStatemerd 

b.  Assignment  Statement 

c.  CirculatixmOperatijQn 

d.  Loop  Statement 

An  If  Statement  is  one  of 

a.  if  Eicprression  then 

\  ^aJtement] 

end; 

b.  if  Expression  then 

[Statementl 

end; 

else; 

I  Statement] 

end; 

An  Expression  is  one  of 

a.  Operand 

b.  Expression  Operator  Expression 

c.  (Expression) 

d.  Exj^ession  and  Eixpression 

e.  Expression  or  Expression 

An  Operand  is  one  of 

a.  Name  Chain 

b.  Name  Chain.  Variable  Name 

c.  Constant 

A  Name  Chain  is  one  of 

a.  VariableName 

b.  Name  Chain  .Variable  Name 

Mapping  names,  constituent  names  and  property  names  can  be  concatenated 
together  to  form  a  chain  [GibbB3]. 

A  Constant  is  one  of 

a.  Number 

b.  "String" 

c.  ? 

d.  current 

e.  here 

The  symbol  "?"  is  used  to  match  any  member  of  a  set.  The  s5mibol  here  refers  to 
the  local  message  and  the  symbol  current  refers  to  the  message  currently 
being  processed. 


An  Operator  is  one  of 
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a.  +• 

b.  - 

c. 

d.  / 

e.  = 

f. 

g-  > 

h,  > 

i.  < 

j  ^ 

k.  in 

l,  conn 

The  operator  in  returns  true  if  the  first  operand  is  a  member  of  the  set  named 
by  the  second  operand.  The  operator  conn  returns  true  if  the  first  operand  is 
connected  to  the  second  operand  (both  operands  must  identify  addresses). 

An  Assignment  State  merit  is 
liiriable  Name  <-  Expression] 

A  CircuiationOperation  is  one  of 

a.  forward  Message  Name  to  Name  , 

b.  share  Message  Name  with  Name  \ 

c.  deliver  Mess  age  Name-, 

d.  drop  Message  Name, 

A  MessageName  is  one  of 

a.  Name 

b.  current 

A  LoopStatement  is 

for  each  Exprression  begin; 

[Statement] 

end; 

A  Relationship  is  one  of 

a.  Name  is-a7Vdme; 

b.  Name  owns  Name ; 

c.  Name  plays  Name] 

d.  Name  connected-to  Name] 

The  user  is  able  to  explicitly  define  the  relationships  that  exist  between 
different  types  and  instances  in  the  MMS.  The  is-a  establishes  the  generaliza¬ 
tion  hierarchy  among  types.  The  owns  establishes  the  superiority  of  roles  for 
sharing  message  access.  The  plays  links  mail  addresses  to  roles  and  the 
connected-to  defines  the  logical  address  network. 
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A  Trigger  is 

define  trigger  Name  begin 
PaitemSection 
[  ConditionSectwn] 

[  No  tifi  c  ationSe  cHon] 

[A:tio7iSectio7i\ 

end 

Only  the  PattemSectiom  is  required  in  a  trigger.  A  trigger  is  applicable  over  the 
set  of  messages  owned  by  the  role  that  defines  the  trigger. 

A  PaitemSection  is 

pattern: 

ActivationPaitem-, 

\  Type  Restric  Hon,  j 

The  PaitemSection  must  contain  an  activation  pattern.  An  execution  of  the 
operation  specified  in  the  activation  pattern  fires  up  the  trigger.  The  pattern 
can  also  contain  type  restrictions  on  any  variables  present  in  the  activation 
pattern. 

An  ActivationPaitem  is  one  of 

a.  ManipvlationOperation 

b.  deliver  PattemName 

A  ManipulaiionOperaiion  is  one  of 

a.  create  a  PattemName  is  Name 

b.  of  PattemName  is  Name 

c.  destroy  PattemName 

d.  assert  PCName  is  Constant  Value 

e.  remove  PCName 

f .  select  Name  is  Msg  Type  where  Expnression 

g.  submit  PattemName 

A  PattemName  is  one  of 

a.  Name 

b.  ?Name 

The  symbol  "?"  prefixed  to  a  name  indicates  that  the  name  is  used  elsewhere  in 
the  trigger. 

A  PCName  is  one  of 

a.  PattemName. Name 

b.  PattemName  .Name 

The  activation  pattern  can  refer  to  particular  properties  or  constituents  of  a 


message. 
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A  ConstantValiLe  is  one  of 

a.  Number 

b.  "Sring” 

c.  Name 

A  Msg  Type  is  one  of 

a.  Name 

b.  POttemName  :Name 
A  Type  Restriction  is 

message  type  of  Name  is  [not]  Name 

The  pattern  may  restrict  firings  to  operations  on  particular  message  types, 

A  ConditionSe  ction  is 

condition: 

I  Eicpression-,  | 
j  Time  Expression-,  | 

The  actions  taken  by  a  trigger  may  be  further  restricted  to  situations  where 
certain  conditions  on  the  properties  of  the  message  are  true  or  to  where  cer¬ 
tain  time  conditions  are  true. 

A  Time  Eirpression  is 
response  is  Number  Time  Unit 

A  limit  on  the  time  taken  to  respond  to  a  message  may  be  imposed. 

A  Time  Unit  is  one  of 

a.  days 

b.  hours 

A  NotificationSe ction  is 

notification: 
alert "  String 

E  a  trigger  is  activated  and  all  conditions  satisfied  then  a  message  can  be 
presented  to  the  user. 

An  ActionSe ction  is 

action: 

{ ManipulationOperation] 

E  a  trigger  is  activated  and  all  conditions  satisfied  then  one  or  more  actions 
may  be  initiated.  We  limit  the  actions  to  a  simple  sequential  series  of  opera¬ 


tions  on  the  communication  base. 
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A  Name  is  one  of 

a.  Letter 

b.  Name  Digit 

c.  Name  Letter 

A  Number  is  one  of 

a.  Digit 

b.  Number  Di^ 

A  String  is  one  of 

a.  Letter 

b.  Digit 

c.  String  Rank 

d.  String  Letter 

e.  String  Digit 

We  let  the  entity  Rank  be  a  single  space,  Letter  be  an  upper  or  lower  case  letter 
of  the  alphabet  and  Digit  be  a  digit  from  0  to  9. 
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Appendix  2 


Journal  Editing  Example 


The  journal  editing  example  introduced  in  Chapter  4  demonstrates  the  use 
of  coordination  in  an  addressing  scheme.  The  addressing  scheme  represents 
the  communication  between  a  journal  editor  and  the  referees  assigned  to 
review  the  submitted  papers. 

A  single  routing  address  can  embody  the  majority  of  the  routing  logic.  The 
address  network  can  consist  of  the  single  routing  address  and  a  mail  address  for 
the  editor  and  each  of  the  possible  referees.  There  are  connections  in  both 
directions  betv/een  the  routing  address  and  the  editor  mail  address  and 
between  the  routing  address  and  each  of  the  referee  mail  addresses. 

The  editor  chooses  three  referees  for  a  paper  and  sends  a  request  to  each 
of  them.  A  request  can  be  represented  as  an  instance  of  a  message  t3q)e 
ReviewR2quest .  The  request  consists  of  a  short  note  from  the  editor  and  a  copy 
of  the  paper.  The  note  can  contain  fields  for  the  date,  the  names  of  the  referees, 
the  title  of  the  paper,  the  due  date  for  the  review  and  some  standard  text.  The 
editor  just  specifies  the  names  of  the  referees  and  the  addressing  scheme 
determines  the  appropriate  mail  addresses. 

The  definition  of  the  message  type  ReviewRequest  is 
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deflne  message  type  RevieivRe.q'iuest  begin 
properties: 

Review  Request  -»  Date,  RBferees+.  Title,  DaeDate,  Body; 

constituents; 

Rei/iew Request  » 

mappings; 

RequestedFbr:  Re  view  Re  quest  ->  Paper; 

Accompanies;  Paper  ^  ReviewRe quest; 

constraints; 

domain  of  Date  is  string(8); 
domain  of  Referees  is  strtng(lO): 
domain  of  Title  is  string(25); 
domain  of  Due  Date  is  string(8); 
domain  of  Body  is  text; 
domain  of  Paper  is  Document] 
end 

The  message  type  ReviewRe  quest  is  an  aggregate  Instances  of  it  can 

contain  a  message  of  the  type  Documerd  (i.e.  the  paper  to  be  reviewed).  The 

message  type  Document  is  defined  as 

define  message  t}!^  Documevt  begin 
properties; 

Document  -*  Title,  Jkut.hors+,  Body; 

constraints; 

domain  of  Title  is  string(26); 
domain  of  Authors  is  string(lO); 
domain  of  Bo  dy  is  text; 
end 

The  editor  can  keep  a  copy  of  the  requests  locally  and  define  a  trigger  that 
is  fired  up  whenever  a  review  request  is  submitted.  The  trigger  will  generate  a 
reminder  to  the  referees  after  a  specified  time  period.  The  trigger  can  be 
defined  as 

define  trigger  Generate  Reminder  begin 
pattern; 
submit  ‘’m; 

message  type  of  m  is  Review  Re  quest] 
condition; 

response  is  30  days; 
action; 

create  a  Reminder  \sml\ 
aissert  ml  .To  is  m. Referees] 
assert  ml.  Title  ism. Title] 

assert  ml. Body  is  "Still  waiting  for  your  review."; 

submit  ml] 
end 

The  message  type  Reminder  can  be  defined  as 
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define  message  t7pe  Rsminder  begin 
properties: 

Reminder  -»  'lUle,  7b +  ,  Body. 
constraints: 

domain  of  Tiile  is  string(25): 
domain  of  To  is  string(l  O); 
domain  of  Body  is  text; 
end 

The  referees,  after  reviewing  a  paper,  will  send  a  message  of  type  Review  to 

the  editor.  The  message  1)^6  can  be  defined  as 

define  message  type  Review  begin 
properties: 

Review  -»  Referee,  lilLe,  Comments] 

constraints: 

domain  of  Referee  is  string(lO); 
domain  of  Title  is  string(2!5); 
domain  of  Comments  is  text; 
end 

The  routing  address  handles  the  forwarding  of  a  message  of  type  ReviewRe- 
quest  to  the  appropriate  mail  addresses  for  the  designated  referees.  The 
address  can  also  coordinate  the  receipt  of  reviews  and  only  forward  them  to  the 
editor  when  all  three  reviews  for  a  paper  are  received.  When  the  routing  address 
receives  a  message  of  t3^e  Reminder  it  can  check  to  see  if  any  reviews  for  that 
paper  are  in  local  store.  If  so,  no  reminder  need  be  sent  to  the  referees  that 
have  already  submitted  their  reviews. 

The  definition  of  the  address  type  for  this  routing  procedure  is  given  below. 
We  assume  there  is  some  facility  Address  (name)  that  returns  the  appropriate 
mail  address  for  the  given  name.  We  also  assume  there  is  some  facility  for 
manipulating  the  array  save.  The  operation  Insert (m, save)  places  the  message 
m  into  save  and  the  forwarding  of  a  reference  automatically  removes  the  mes¬ 
sage  from  save. 
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define  address  type  Journal  touting  begin 
properties: 

Journal  Routing  ->  Address Id\ 

constraints: 

domain  of  Addressld  is  string(6); 
routing: 

instance  variable  save(  100)  reference; 

variable  nxrme  string(lO); 

variable  count  integer; 

variable  m  reference; 

variable  received(lO)  string(lO); 

begin; 

case  (type  is  ReviewRe  quest)  begin; 
for  each  name  in  current.^e/erees  begin; 

share  current  with  Address  (name): 
end; 

drop  current; 
end; 

case  (type  is  Review)  begin; 
count  <-  0; 

for  each  m  in  save  begin; 
if  m.  Title  =  current.  Title  then 
count  <-  count  +  1; 
end; 
end; 

if  count  <  2  then 
Mserf  fcurrent.sa^;e^; 
end; 
else; 

fw  each  m  in  save  begin; 
if  m.  Title  -  current. Ti/ie  then 
forward  m  to  editor: 
end; 
end; 

forward  current  to  editor-, 
end; 
end; 

case  (type  is  Reminder)  begin; 
count  <  0; 

for  each  m  in  save  begin; 
if  (current.  TlifZe  =  m  Title)  and 

{m. Referee  in  current.  7b)  then 
count  <-  count  +1; 
received(count)  current. 7b; 
end; 
end; 

for  each  name  in  current.  To  begin; 
if  ~(name  inreceived)  then 
share  current  with  Address  (name  ): 
end; 
end; 

drop  current; 
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